Revealing Invisible Requirements


No matter how thorough a job you do on requirements elicitation, there is no way to be certain that you have found them all. No little green light comes on to announce “You’re done!” You should always plan on new requirements trickling in throughout the project. However, an excessive rate of change of requirements suggests that important requirements were overlooked during elicitation. This article, adapted from our new book Software Requirements, 3rd Edition, offer some suggestions for closing gaps caused by missing, implied, and assumed requirements.

Missing Requirements
Revealing Invisible RequirementsMissing requirements constitute a common type of requirement defect. Missing requirements are hard to spot because they're invisible! The following techniques will help you detect previously undiscovered requirements.

  • Decompose high-level requirements into enough detail to reveal exactly what is being requested. A vague, high-level requirement that leaves much to the reader's interpretation will lead to a gap between what the requester has in mind and what the developer builds.

  • Ensure that all user classes have provided input. Make sure that each user requirement has at least one identified user class who will receive value from the requirement.

  • Trace system requirements, user requirements, event-response lists, and business rules to their corresponding functional requirements to make sure that all the necessary functionality was derived.

  • Check boundary values for missing requirements. Suppose that one requirement states, "If the price of the order is less than $100, the shipping charge is $5.95" and another says, "If the price of the order is more than $100, the shipping charge is 6 percent of the total order price." But what's the shipping charge for an order with a price of exactly $100? It's not specified, so a requirement is missing, or at least poorly written.

  • Represent requirements information in more than one way. It's difficult to read a mass of text and notice the item that's absent. Some analysis models visually represent requirements at a high level of abstraction—the forest, not the trees. You might study a model and realize that there should be an arrow from one box to another; that missing arrow represents a missing requirement.

  • Sets of requirements with complex Boolean logic (ANDs, ORs, and NOTs) often are incomplete. If a combination of logical conditions has no corresponding functional requirement, the developer has to deduce what the system should do or chase down an answer. “Else” conditions frequently are overlooked. Represent complex logic by using decision tables or decision trees to cover all the possible situations.

  • Create a checklist of common functional areas to consider for your projects. Examples include error logging, backup and restore, access security, reporting, printing, preview capabilities, and configuring user preferences. Periodically compare this list with the functions you've already specified to look for gaps.

  • A data model can reveal missing functionality. All data entities that the system will manipulate must have corresponding functionality to create them, read them from an external source, update current values, and/or delete them. The acronym CRUD is often used to refer to these four common operations. Make sure you can identify functionality in your application to perform these operations on all of your entities that need them.

Watch out for the dreaded trap of analysis paralysis, spending too much time on requirements elicitation in an attempt to avoid overlooking any requirements. At some point you need to establish a relatively stable requirements baseline that describes what you’ll be implementing in the next release or iteration. But expect to perform some additional elicitation throughout the course of the project, no matter what life cycle the project is following.

Assumed and Implied Requirements
I once encountered a development team that was implementing a content portal that was intended to do many things, including upload, edit, and publish content to a website. There were approximately 1,000 pieces of existing content, organized in a hierarchy. The content management team assumed that users would be able to navigate the hierarchy to quickly find a specific piece of content for editing. They did not specify requirements regarding the user interface navigation. However, when the developers implemented the user interface to navigate to content, they organized all of the content in a single level, not hierarchically, and showed only 20 items per screen. To find a specific piece of content, a user might have to navigate through as many as 50 screens. A little more specification and dialogue between developers and the content management team could have avoided considerable rework.

 You will never document 100 percent of the requirements for a software system. But the requirements you don't specify pose a risk that the project might deliver a solution different from what stakeholders expect. Two likely culprits behind missed expectations are assumed and implied requirements.

Assumed requirements are those that people expect without having explicitly expressed them. What you assume as being obvious might not be the same as assumptions that various developers make. Implied requirements are necessary because of another requirement but aren't explicitly stated. Developers can't implement functionality they don't know about. Assumed and implied requirements both rely on a certain amount of telepathy and clairvoyance, which are not strong technical foundations for a software project.

To reduce these risks, try to identify knowledge gaps waiting to be filled with implied and assumed requirements. Ask, "What are we assuming?" during elicitation sessions to try to surface those hidden thoughts. If you come across an assumption during requirements discussions, record it and confirm its validity. People often assume that things have to be the way they've always been because they're so familiar with an existing system or business process. If you're developing a replacement system, review the previous system's features to determine whether they're truly required in the replacement.

To identify implied requirements, study the results of initial elicitation sessions to identify areas of incompleteness. Does a vague, high-level requirement need to be fleshed out into more detail so the stakeholders all understand it? Is a requirement that might be part of a logical set (say, saving an incomplete web form) lacking its counterpart (retrieving a saved form for further work)? You might need to re-interview some of the same stakeholders to have them look for missing requirements. Also, think of new stakeholders who know the topic and can spot gaps.

Read between the lines to identify features or characteristics the customers expect to be included without having said so. Ask context-free questions, high-level and open-ended questions that elicit information about global characteristics of both the business problem and the potential solution (see Exploring Requirements: Quality Before Design by Donald C. Gause and Gerald M. Weinberg, Dorset House Publishing, 1989). The customer's response to questions such as "What kind of precision is required in the product?" or "Can you help me understand why you don't agree with Miguel's reply?" can lead to insights that questions with standard yes/no or A/B/C answers do not.

We all know that you’re not going to discover and document every single requirement for a software system of any size. If you keep your eyes open for missing, assumed, and implied requirements, though, you’ll close a lot of the gaps that otherwise might cause development headaches farther down the road.

Author: Joy Beatty is a Vice President at Seilevel, Karl Wiegers is Principal Consultant at Process Impact, Karl and Joy are co-authors of the recently-released book Software Requirements, 3rd Edition (Microsoft Press, 2013), from which this article is adapted.

Like this article:
  36 members liked this article


Alan posted on Thursday, July 24, 2014 5:02 PM
Another technique or concept I have found useful is to identify and understand the Lifecycles involved. It is an extension of data modeling that tries to look beyond the basic Create, Read, Update and Delete activities because that can end up being a technical exercise to document the CRUD for each specific entity and perhaps who can perform each CRUD activity.
Lifecycles can group related tables together, and generate questions about the 'business processes' that should maintain them, and not just make sure a CRUD capable UI is available for that.
For example:
1. For tertiary scholarships there are separate but linked lifecycles for: Create Scholarship, Manage Related Investment, Periodically Confirm Availability, Students Submit Applications, Evaluate and Award Scholarship, Pay Scholarships, Close Scholarship etc.
2. Standard Sales lifecycles for: Create and approve new customer, Record Credit Sales, Process Payments, Credit Management etc.
3. What about a new application's internal list of current Organizational Business Units and of people who can authorize specific decisions. The new system can have a UI to maintain an internal list of current business units and authorized people, but you may also need to integrate with or set up manual changes to the master Organizational Change and People based processes to ensure the new application is kept up to date with changes.
4. What about a system where the UI carries out CRUD activities for the selected parent entity, but does not show details and complexity for the lower level related child entities. E.g. Database referential integrity supports CRUD functions and prevents accidental deletions etc, but before an end date to make the parent item inactive can be set, a project is required to assess the impact and identify the nature of other separate specific child entity changes that should be done first.
Alan Maxwell
Alan posted on Thursday, July 24, 2014 5:52 PM
Thank you for that very good list.

I have also found it useful to extend the use of the 'Checklist'.

I have built up a master list of 'Requirement Types' and on projects I assign one of these to each requirement (after making sure the requirement is written so it is clear and specific enough that only one should apply).

For example a Data requirement is flagged as being one of the following major Data lifecycle types:
• DK: System Parameters (mainly technical)
• DL: Reference Data [1] (e.g. company and business unit names, period data, available statuses etc)
• DM: Masterfile Data [1] (e.g. customers, suppliers, inventory items, people etc)
• DP: Price & Rate Data [1] (these can change over time)
• DT: Transaction Data [1] (e.g. invoices, payments in financial system)
• DU: Summary/Derived Data [1]
• DZ: Logs (Audit/Errors/Changes[
The major groups of requirement type are: Bx: Triggers, Dx: Data, Ex: Data Capacity (current + future), Fx: Business Functions + Processes, Ix: Interfaces, Ox: Other (e.g. Legal), Vx: Vendor Capabilities and Xx: Non-functional.

When each requirement is mandatorily associated to both a Functional Area ]2[ and a Requirement Type, a cross tabulation count of requirements by Functional Area and Requirement Type can give interesting results and highlight areas to follow up for potential gaps where there are very few key Requirement Types in certain functional areas.

Note: Using a Requirements Management System that can endorce mandatory recording of Requirement Types, 'search on' and generate such a cross tab analysis on demand is helpful.

]1[ This is normally database stored data in an IT system, and there are common relationships between each one.
]2[ The Major Functional Areas for the application (E.g. Customer, Sales, Vendor, Purchases, Cash, Payroll, Overall System within a Financial application etc.]
Alan Maxwell
Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC