Skip to main content

Author: Zenobia Godschalk

Are We There Yet?

Written by Zenobia Godschalk on . Posted in Articles. 1 Comment on Are We There Yet?

Zeena_Feature_March22_modifiedIn my previous blog (http://www.batimes.com/articles/requirements-development-101.html), I described requirements development (RD) and its activities. After reading the blog, some of my customers inquired “just how long does it take to do proper requirements development?” Honestly, there is no set time to this question. However, I can categorize some environmental factors that can extend the time required for proper requirements development. You should add time to your RD schedule in the following situations:

  • Skill level of the analyst and process maturity –
    • if the project has less experienced analysts;
    • if there are no standard RD activities or documentation in place;
    • if there is no reuse of the requirements;
    • if there are no peer reviews throughout the RD phase;
    • if you don’t store requirements in a single repository.
  • User involvement –
    • if there is none or very little user involvement or
    • if there are many types of users.
  • Stakeholders’ response time –
    • if the stakeholders are not co-located;
    • if there are languages or cultural barriers;
    • if key decision-makers with conflict resolution power are not identified.
  • Project size and complexity –
    • if you are building a new application versus rewriting a legacy application;
    • if you are re-engineering your processes AND building the application at the same time;
    • if you have external interfaces;
    • if the developers or testers are not knowledgeable in the application being defined.

I always tell my customers to use historical data when determining the RD effort and adjust their time estimate by addressing the above environmental factors. If you don’t have historical data, then it’s never too late to start collecting some metrics from your current RD efforts. Unless you are following a strict waterfall methodology, I wouldn’t create a onetime estimate from my entire set of requirements, but instead create estimates for each incremental phase. Also, I set the expectation that with each incremental phase, the estimates will change, but they will also be more accurate because you will know the health of your project better as you execute through its life cycle.

For example, Agile projects have numerous, very small RD phases. Agile teams do “just enough” requirements definition before proceeding to development and testing. This allows for the users and stakeholders to rapidly provide feedback to the analyst, which results in improving the requirements development efforts with each iteration. The length of time of an increment doesn’t matter as long as the stakeholders and users understand the requirements for that specific iteration. If they don’t, then you will repeat the rework efforts of the past iterations.

Whenever a customer asks me “Are We There Yet?”, it leads me to believe that they want to speed through the requirements development phase – just to say they did it. It has been shown that spending more time on requirements can accelerate software development by decreasing rework activities. We all know that requirements issues are one of the major causes for project pain.

The Standish Group asked their survey participants about the reasons that cause their projects to be” challenged”. Below are the percentages reported by their CHAOS Report, they define “challenged” as “the project is completed and operational, but over-budget, over the time estimate, and with fewer features and functions than initially specified”:

Project Challenged Factors % of Responses
1. Lack of User Input 12.8%
2. Incomplete Requirements & Specifications 12.3%
3. Changing Requirements & Specifications 11.8%
4. Lack of Executive Support 7.5%
5. Technology Incompetence 7.0%
6. Lack of Resources 6.4%
7. Unrealistic Expectations 5.9%
8. Unclear Objectives 5.3%
9. Unrealistic Time Frames 4.3%
10. New Technology 3.7%
Other 23.0%

This indicates that three of the biggest issues leading to project pain are due to poor requirements engineering. What this really means is that when the project was delivered, there was a difference between what the stakeholders and users needed or wanted, and what the developers built. Better software requirements can lessen this difference, which can provide numerous benefits to all the project members.

  • Project Managers – Better requirements enable organizations to effectively decide which projects to fund because better requirements show a more precise estimation of business return on investment.
  • Product Mangers – Once a project is selected, better requirements help in the assessment of effort and resources because the complexity of the requirements can be correlated to development and testing efforts.
  • Analysts – All features may not not be able to be delivered, so better requirements allow the team to prioritize the features more effectively. This will make certain that the project executes the most important functionality.
  • Design and development teams – Because requirements establish product design, better requirements facilitate the design and development team to more effectively select the right solution.
  • QA teams – Better requirements allow the prioritization of features thus enabling the testers to focus on developing the important test cases first.

As we know, it is more expensive to fix defects later in the software development cycle than during requirements development. Consequently, your company’s profits can be influenced and correlated to requirements issues. Therefore, it is crucial to invest in better requirements activities rather than solely worrying about how long it takes to do proper requirements development. This estimation will improve with time once you’ve established a good requirements practice.

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 Development 101

Written by Zenobia Godschalk on . Posted in Articles.

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.

Testing, Testing, 1, 2, 3…

Written by Zenobia Godschalk on . Posted in Articles. 1 Comment on Testing, Testing, 1, 2, 3…

BAtimes_Feature_Oct_25_CroppedA use case describes a system’s behavior as it positively or negatively responds to a request from a stakeholder under various conditions. Thus, use cases provide a convenient user/functional test description for the system under definition. I find most Quality Assurance groups would rather work with use cases versus requirement statements when generating test cases. As organizations mature into a Quality Center of Excellence, it decreases a tester’s ability to know the systems under test in any detail because they are tasked out to test just about everything in that organization. Also for these QA groups, it is usually the first time they have been given the requirements to base their test cases.

Use cases are something very easy to work with to generate those test cases because use cases already contain the basic and alternate flows of the software behavior. Therefore it makes it easier for a tester to know the positive or negative tests that need to be created. Test generation becomes difficult if the tester has only requirements statements to work from because certain behavior descriptions may be missing. As a result, the tester usually ends up guessing all the ways a piece of functionality needs to be tested or has to re-interview the stakeholders to ensure everything is being tested. Therefore, if the various behaviors of the software are not detailed in use cases, then the testers will have a difficult time discerning the right behavior from a defect. I have found in some organizations that the testers work with the business analysts to help write the use cases. QA folks will need to write test cases at some point in the software development life cycle (SDLC), so why not include them from the beginning by getting their help in writing the use cases which will later evolve into test scenarios and test cases.

On many projects, testing is later in the SDLC. Requirements defects remain in the software until they are discovered in the testing phase. At User Acceptance Testing (and production), significant dollars are required to fix requirement errors after the development teams have already built functionalities based on those requirements. We have all read studies that have shown the cost can be up to 100 times more to fix a requirement defect found by an end user than to fix that same defect found during requirements definition. In our experiences, we have seen an error found during requirements development can take only minutes to fix, versus that same defect found at UAT takes hours or days to fix. We all know any action we can take to find defects in requirements definition will absolutely save us time and money.

If you start generating test cases earlier in the SDLC, you’ll detect requirements defects shortly after they are made. This stops these defects from filtering into the rest of the SDLC and cuts your testing and maintenance costs. So as soon as use cases(s) are approved by the stakeholders, the test team can divide each use case into numbered tests and write an execution plan. In addition, they can create all the data needed to test the different data permutation. The main basic flow test case should come first because you always want to test how the software behaves in a high volume scenario. It should be created before all of the alternate flow test cases. On a side note, the main basic flow lends itself very well to performance/load testing because it is a high volume scenario.

Thanks goodness for modern technology. Today, there are software products out there that allow analysts, stakeholders, testers, and developers to visually walk through use cases together, thus allowing them to share a clear vision of how the software will behave. By visually tracing the basic and alternate paths for each use case, you can find incorrect, missing, or unnecessary requirements, which can be fixed long before any code is written. After the use cases have been approved by all parties, the requirements center can automatically produce test scenarios. These test scenarios are created from the use cases and have traceability to the functional and user requirements of the software. The QA team can take these auto generated test scenarios and modify them to create test cases. The test cases a are detailed set of tests with specific test data used by a tester to record the expected results. This technique of visualization controls a project’s cost and schedule by finding requirement errors very early in the SDLC.

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.