Skip to main content

Author: Zeena Kabir

Requirements Development 101

Many organizations that I work with understand that better requirements engineering practices would alleviate many pains in their current software development lifecycle (SDLC). But some of these organizations don’t know how to improve their practices because, I believe, they don’t fully appreciate the world of requirements engineering. So I am writing this article to describe, at a high level, the components that make up requirements engineering. Once the components are understood, then organizations can see what is missing or what needs to be modified in their current environment to arrive at a better practice.

First, let’s define the term requirements. There are millions of web sites that can give you this definition, so I went with Wikipedia (http://en.wikipedia.org/wiki/Requirement). It states that “a requirement is a singular documented need of what a particular product or service should be or perform”. This, to me, means there are many, many kinds of information that fit into this thing called “requirements”. To simplify the matter, let’s start breaking down these kinds of information into categories, or different “types” of requirements. At a minimum, an organization should collect these types:

  • Business Requirements -describes the values this project will provide the organization once it is finished. Some organizations have a vision and scope document, while others just roll it into the generic Business Requirements Document (BRD).
  • User and Functional Requirements, and Business Rules – these describe what the software needs to do and what the development teams need to build. Some organizations have a Use Case or Functional Requirements Specification (FRS) document, while others have it in the one BRD.
  • System and Data Requirements, Quality Attributes, External Interfaces, and Constraints – these types are just a handful of non-functional requirement types that you can collect. Some organizations have a Software Requirements Specification (SRS), while others have it in that BRD, which seems to be looking pretty big right now.

Now that we know what to collect, we need to understand how to collect them. Requirements engineering is broken down into two activities: requirements development (RD) and requirements management (RM). I find most organizations do requirements management well. This is to say, they can manage changes to a set of baselined requirements that have been identified to a specific release. What I find is most organizations have a hard time setting a standard practice around requirements development. I will spend the rest of the article describing this activity. RD is broken down into the following sub-activities:

  • Elicitation – this involves interviewing the stakeholders and determining their needs. This is not writing down everything they say. Stakeholders will not know everything they need the first time you interview them. What they do know, may not fit into the scope of the project or may not be in agreement with the next stakeholder you interview, or may even be wrong. Therefore, elicitation is an iterative and inventive activity. Think of yourself as a detective that asks the questions that gets the stakeholders to think of missing or new requirements that are within the scope of the project. A good way to get the stakeholders to open up is to ask all the “What if …” questions. Another very useful technique to use is to ask “Why?” These questions can reveal missing or unspoken requirements or offer additional details to enhance the understanding of a requirement. Creating these types of dialog is an effective way to increase the completeness and quality of the requirements versus just writing down everything that they say.
  • Analysis – this involves developing detailed requirements from elicitation. These detailed requirements don’t need to be just textual in nature. They can be of different forms, such as business process diagrams, data models, use cases, and prototypes. By gaining greater detail, you will also discover missing requirements. Analysis offers an effective way to recursively refine the understanding of the initial elicited requirements. This is also where you will settle priorities of requirements between stakeholders and arbitrate between conflicting requirements. Because the analyst is the communication hub with all the stakeholders, it is a good idea to identify key decision-makers that will have the final yea or nay power when conflicts arise. This will become even more important when you communicate the requirements downstream to the testers and developers, therefore quick and efficient conflict resolution process is important.
  • Specification – this involves documenting the various types of requirements, which can be textual or graphical. It is usually a good idea to have a few documentation standards for vision and scope document, FRS, SRS, BRD, etc. Many analyst web sites have examples of these types of document standards.
  • Validation – this involves making sure that the requirements are correct and will meet the stakeholders’ needs. One good way to validate requirements is to have the stakeholders develop user acceptance criteria. These criteria specify the primary tasks the software will allow the users to perform and the common errors that the software will handle. Comparing the requirements against the user acceptance criteria will establish if the requirements are correct. On a side note, they also provide starting points for testing scenarios for the quality assurance team.

I would like to point out that you don’t need to develop all the requirements for the entire project at once. Requirements development is an iterative process, so trying to develop detailed requirements all at once can lead to analysis paralysis. During elicitation, you will identify the high priority or first built features. Start with analysis and specification of these requirements and do validation with a quick informal review. Then move to the next set of elicited requirements for analysis and specification, all the while correcting the previous set of requirements of missing or misunderstood requirements that are discovered along the way. By infusing quick review cycles between analysis and specification, you will filter out errors and increase the completeness and quality of the requirements with each cycle. Having multiple cycles will refine the requirements to a level of detail that can be efficiently communicated to the stakeholders, testers, and developers. At the end of the day, a project will never have a set of perfect requirements, but it will have a good enough set of requirements to proceed to development and testing. Since we can never produce a perfect set, we want to adopt practices that result in fewer requirement defects, especially the ones that have high impact and severity. We can weed out these nasty defects before they are injected into the SDLC. This can decrease the amount of development rework, which results in reduced product cost and quicker time to market.

On a final note, to further increase efficiencies in your requirement development activities, you should input all of the requirements in a single repository. It lets you capture elicited requirements and you can you can easily access them for usage as the basis for initial development of detailed use cases, UI mockups, data models and business process diagrams during analysis. Also a requirements repository allows you to trace any requirement to any other requirement. Since it is a repository, you can trace across all these elements to see all the dependencies and evaluate the impact of changes.

Don’t forget to leave your comments below.


Zeena Kabir is a Sales Engineering Consultant for Blueprint Software, the leader in requirements definition and visualization software. Prior to Blueprint, Zeena has worked 20+ years in the IT field in the areas of requirements engineering, testing, and development. She holds a Bachelor of Science degree in Computer Science and a Master of Science degree in Software Engineering from the University of Maryland. She resides and works with many IT organizations in the Mid-Atlantic region.

Requirements – To Detail or Not Too Detailed

Dec15-ZeenaFeatureIn recent years, I have discovered that more and more organizations are writing use cases to clearly understand the behaviors of their systems.  Working with these organizations, I usually get the question “What Use Case standard should we utilize?”  The answer depends on the project situation.  I have utilized two simple use case formats that will help you document use cases in some of the following common situations:

 

  1. Drawing out requirements for new features or functions
  2. Writing requirements on short iterations (e.g. Agile)
  3. Redesigning a process or feature or function
  4. Writing detailed requirements on incremental or longer projects

For Drawing out Requirements or Writing Requirements on Short Iterations

Use cases are a great way to discover requirements.  Stakeholders find the narrative format easier to understand than a long list of requirements because they can see the behavior of the system.  This is very helpful in situations where you have a brand new feature/function.  The use case initiates a visualization of the new feature, which can then be iteratively modified to fit the needs of each stakeholder.  This allows for eliciting ideas on how the new feature may or may not let an actor reach its goals in the current system.  For this type of use case, create a high-level view of how you think the new feature will behave.  Create the main basic flow and walk through this flow of the new feature with stakeholders.  Once the basic flow is accepted, then consider the alternative flows at a high level.  These alternate flows are going to help you find missing requirements that you may not have thought of for the new feature/function.  This is going to guide you to superior requirements that are well thought-out and more complete.

The goal for this type of use case is to provide quick analysis and acceptance, usually in a live review session.  It is assumed that you are working in a group with good internal communications when using this format for a project with short iterations. 

Here is a simple format for such a use case:

Use Case Name:

Scope: the extent of the new feature that will be designed/developed.

Primary Actor:

Triggers: This describes the event(s) that causes the new feature to be initiated

Preconditions: This describes all the conditions that are true before the new feature can be initiated.

Postconditions: This describes the change(s) the new feature will have in the current system, positively and negatively.

Basic flow: A paragraph of a high level, top down description of the typical set of actions in which the goal(s) is delivered.

Alternate flows: A paragraph for all the other flows.  Each alternate flow paragraph should start with a condition/trigger and a goal for the alternative flow.  It should contain a high level, top down description of what happens for that condition/trigger, and end with the success or failure of the extension goal.

For Redesigning the Process/Feature/Function or Writing Detailed Requirements on Incremental or Longer Projects

This type of use case is for situations where you need to redesign a process or a function/feature.  If you have existing requirements or use cases, then you have a place to start.  If you don’t (many times, this is the case), then you will need to do one of two things.  If time permits, then reverse engineer the behavior of the process/feature/function in a use case.  This will give you a baseline and a way to validate with stakeholders what is current before you make any changes to the system.  If you don’t have time, then just start documenting the changes.  At least, you will end up with some level of documentation regarding the system behavior, which is better than nothing.

Here is a sample format for a detailed use case:

Use Case Name:

Scope: the extent of the change that will be designed/developed.

Primary Actor:

Triggers: This describes the event(s) that causes the changed process/feature to be initiated.

Preconditions: This describes all the conditions that are true before the changed process/feature can be initiated.

Postconditions: This describes how the changed process/feature will modify the current system, positively and negatively.

Basic flow: This is the top down description of the typical set of actions in which the goal(s) is delivered.  Number the steps to make the sequencing stand out.  If you are starting from an existing use case, then I would bold the steps that reflect the changes.  This will allow the reviewer to hone in on areas that are being redesigned.

Alternate flows: These are all the other flows whose steps are also numbered for sequencing.  It starts with a condition/trigger and a goal for the alternative flow.  It contains a sequence of action steps describing what happens for that condition/trigger.  It ends with the success or failure of the extension goal.  Failure handling description is important to this type of use case because you will discover new business rules.  Again, if you are working from an existing use case, then I would bold the steps that reflect the changes to the process/feature.

You should have a template for a simple and detailed use case definition and utilize one when the situation arises.  Don’t over analyze too much about the exact format for your organization.  But do create detailed-enough formats where it’s easy for you to review with your stakeholders.

Don’t forget to leave your comments below


Zeena Kabir is a Sales Engineering Consultant for Blueprint Software, the leader in requirements definition and visualization software. Prior to Blueprint, Zeena has worked 20+ years in the IT field in the areas of requirements engineering, testing, and development. She holds a Bachelor of Science degree in Computer Science and a Master of Science degree in Software Engineering from the University of Maryland. She resides and works with many IT organizations in the Mid-Atlantic region.