DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
View Events Video Library
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Integrating PostgreSQL Databases with ANF: Join this workshop to learn how to create a PostgreSQL server using Instaclustr’s managed service

Mobile Database Essentials: Assess data needs, storage requirements, and more when leveraging databases for cloud and edge applications.

Monitoring and Observability for LLMs: Datadog and Google Cloud discuss how to achieve optimal AI model performance.

Automated Testing: The latest on architecture, TDD, and the benefits of AI and low-code tools.

Related

  • The Next TCP/IP Moment in Identity
  • A New Approach to Traceability Can Solve Software Product Validation Issues
  • Decoding Business Source Licensing: A New Software Licensing Model
  • Unpacking the 'As-a-Service' Model

Trending

  • Four Ways for Developers To Limit Liability as Software Liability Laws Seem Poised for Change
  • TypeScript: Useful Features
  • Extracting Maximum Value From Logs
  • Securing Your Applications With Spring Security
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. Software Requirements: How to Find Out What Users Want

Software Requirements: How to Find Out What Users Want

Users often don't know exactly what they want. By dissecting the user base, developers can understand requirements for developing successful applications.

Marco Behler user avatar by
Marco Behler
CORE ·
Aug. 27, 15 · Opinion
Like (5)
Save
Tweet
Share
5.22K Views

Join the DZone community and get the full member experience.

Join For Free

In the last posts we talked a lot about dissecting requirements. But there was always one silent assumption: That your users and in turn your boss/client more or less all know exactly what they want.

In reality, however, users often do not know exactly what they want. Or maybe they do not know a proper way to figure it out.

So how we change that? How do we stop building software for the trash can and start building exactly what users want?

As Always

Before we jump straight to the question of “how do we find out what users want," we first have to dissect our userbase a little bit.

Note that we are primarily talking about line of business software, from your favourite SaaS start-up to the package & shipping desktop application you might use in your company. (I could not tell you much about e.g. games, and what users really want in games, but for most other types of software, similar rules apply.)

The "Natural" Requirement

This one is the most straightforward one, as you have (existing or future) users directly asking for it or even demanding it.

Imagine you run an e-commerce shop: of course you want to have an easy-to-access list of all your purchases, including their prices, customer names etc.

Or you have an accounting software, which needs updates every year as the government regulations and laws change, just like with the EU’s VAT laws in 2015.

Or you are a doctor, running some software for patients, and of course you want to see a patient’s medical history when you open up his file. What did you to/with him last time he visited you? Any images, CAT scans taken?

These examples might seem almost too obvious, but remember: Natural requirements are those that a user really needs in place to get his job/work done.

The "Hidden" Requirement

Hidden requirements are a bit trickier and you can think of them in terms of improvements to current, already existing workflows. Let me explain, getting back to that doctor’s example, assuming you are a doctor’s assistant:

When a new patient comes in, you might open up his file, take some notes and maybe attach a couple of newly taken pictures to his file. Then you close his file and later on, in the last week of the month, you have to do some invoicing and billing for that patient and all other patients you treated.

Imagine you are already using some patient CRM software and the only thing it can currently do is to give you a list of all patients from last month. Now imagine the following scenario, with 500 patients:

Some of them you immediately invoiced after their visit. Some of them you do in batches at the end of every week of the month. But some you cannot invoice because some details are missing and you postpone them to the end of the month.

The problem is: When you open up that list of all patients from last month, you have no clue anymore who you already invoiced, who still has stuff missing, because there is no filter, no easy way to visually see who has been invoiced etc. It grows worse every month and it literally takes you ages to work off that list.

What you, as the doctor’s assistant want is not a list of all patients who visited you last month, but a list of “still-to-invoice” patients, ideally displayed, almost pushed on to you automatically at the end of the month, considerably cutting down your work time and efforts.

To sum up this example: You have already a workflow in place, which also somewhat works. But it could be improved considerably, always with the goal to cut costs/improve workflows/increase profits. These are “hidden requirements”.

The "Hallucination" Requirement

Now we come to my favourite type of requirement, the hallucination requirement, often sold to you as “revolutionizing” an industry through “major innovation”.

The main difference to the two previous types is that you do not have direct contact with your customers and you do not want to take small, incremental steps. Instead you sit in your room and assume you know what your customers want and want to offer them the perfect, big bang solution. Yes, the masses would definitely buy XYZ, they have been waiting for it for ages. It is so revolutionary! Let’s build it!

There is of course a chance that you could be right and you hit the right nerve. Kudos to you. But more often than not you are looking at an ego-maniacal product owner, who dreams of being the next Steve Jobs and cashing out on the “start-up” ASAP, instead of building a profitable, long running business.

Note that, in a lot of old-boring business to business contexts this is almost impossible to pull off for too long: Well, yes, your accounting software needs to be able to handle VAT calculations in the EU and end-users do not care if the software is written with AngularJS 2.0. So it will be a lot harder to hallucinate.

Next Step

This chapter was a rough classification of requirement types. The next blog post will cover specific strategies to handle each type of requirement and issues that might pop-up along the way.

Stay tuned!

Requirement Software

Published at DZone with permission of Marco Behler. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • The Next TCP/IP Moment in Identity
  • A New Approach to Traceability Can Solve Software Product Validation Issues
  • Decoding Business Source Licensing: A New Software Licensing Model
  • Unpacking the 'As-a-Service' Model

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends: