Software Requirements - Part 4

This is the forth part of the following book summary.

Previous posts:

• Software Requirements - Part 1
• Software Requirements - Part 2
• Software Requirements - Part 3

Requirements Validation

Validation ensures that the requirements exhibit the desirable characteristics of excellent requirement statements (complete, correct, feasible, necessary, prioritized, unambiguous and verifiable) and of excellent requirements specifications (complete, consistent, modifiable and traceable).

Informal reviews are useful for educating other people about the product and collecting unstructured feedback.

If you are serious about maximizing the quality of your software, your team will inspect every requirements document it creates.

Inspection has been recognized as a software industry best practice.

The participants in an inspection should represent four perspectives:

• The author of the work product and perhaps peers of the author
• The author of any predecessor work product or specification for the item being inspected
• People who will do work based on the item being inspected
• People who are responsible for work products that interface with the item being inspected

It is useful to create a defect checklist to help inspectors look for typical kinds of errors in the products they inspect. Some studies have shown that giving inspectors specific defect-detection responsibilities is more effective than simply handling all inspectors the same checklist.

As with all quality activities, make a risk-based decision as to how much energy to devote to improving requirements quality.

Considerations:

• For large requirements documents perform incremental reviews or identify high-risk areas that need a careful look and use informal reviews for less risky material
• Keep the number of reviewers small because large inspection teams make it hard reaching agreement on issues

Testing the Requirements

It's hard to visualize how a system will function under specific circumstances just by reading the SRS. Writing black box (functional) test cases crystallizes your vision of how the system should behave under certain conditions. Dialog maps can be useful to describe test cases and by tracing the execution path, you can find incorrect or missing requirements.

Acceptance testing should focus on anticipated usage scenarios. Acceptance tests focus on the normal courses of the use cases, not on the less common alternative courses or whether the system handles every exception condition properly.

User acceptance testing does not replace comprehensive requirements-based system testing, which covers both normal and exception paths and a wide variety of data combinations.

Acceptance test planning, informal reviews, SRS inspections and requirements testing techniques will help you to build higher-quality systems faster and more inexpensively than you ever have before.

Maintenance

Maintenance often consumes the majority of a software organization's resources. 

Maintenance programmers typically correct defects, add new features or reports to existing systems, and modify functionality to comply with revised business rules.

The requirements specification for the next release of a mature system often says essentially:

"The new system should do everything the old system does, except add these new functions and fix those bugs"

And often there is not a description of the original system!

In absence of accurate requirements documentation, maintainers must reverse-engineer and understanding of what the system does from the code. Begin by recording the new requirements in a structured, if incomplete, SRS or in a requirements management tool.

When you add a new functionality, you'll have to figure out how new screens and features will interface to the existing system.

Building a requirements representation that includes portions of the current system achieves three useful goals:

• Future maintainers better understand the changes that were just made
• It collects some information about the current system that previously was undocumented.
• It provides an indication of functional coverage by the current set of system tests.

Some other techniques that you can try on a small scale during maintenance include:

• Creating a data dictionary
• Drawing analysis models
• Specifying quality attributes and performance goals
• Building user interface and technical prototypes
• Inspecting requirements specifications
• Writing test cases from requirements
• Defining customer acceptance criteria

Any existing requirements representations must be kept current during maintenance. 

There is a widespread fear in the software industry that writing documentation will consume too much time.

The decision is yours and you should do it based on the question:

What is the cost if you don't update the requirements and a future maintainer has to regenerate that information?

What if you are purchasing a commercial off-the-shelf product (COTS) as part of a new project?

You still need requirements because typically this products need to be configured, customized, integrated and extended to work in the target environment. You should focus on requirements at the user requirements level and use cases work well for this purpose. Obviously COTS give the acquiring organization less flexibility over requirements than does custom development.

What about outsourced projects?

Contracting product development to a separate company demands high-quality written requirements because your direct interactions with the engineering team are likely to be minimal.

What about emergent and fast-moving projects?

This kind of projects has led the creation of various agile development methodologies that emphasize rapidly putting useful functionality into the hands of users. The agile methodologies take a lean approach to requirements development and an informal approach to requirements management. Requirements are described in terms of product features or in the form of user stories.

Detailed requirements documentation is rejected in favour of continuous interaction with an on-site customer representative.

The agile development philosophy views software change as both inevitable and desiderable. This agile approach works well for dealing with a high degree of requirements uncertainty in information systems of internet projects. It's less well suited to applications whose requirements are well understood and to embedded systems development.

The requirements for rapidly changing projects are too unstable to justify investing a lot of requirements development effort up front.

Regardless your development methodology frequent conversations between project team members and appropriate customers are the most effective way to resolve many requirements issues. Written documentation, however detailed, is an incomplete substitute for these ongoing communications.

Don't expect a single individual to resolve all the requirements issues that arise. The product champion approach, with a small number of user representatives, is a more effective solution.

Beyond requirements development

The most important thing is that all project stakeholders reach a shared understanding of their business objectives and the users' needs.

Experienced project managers and developers understand the value of translating software requirements into robust designs and rational project plans.

Considerable evidence shows that taking time to understand the requirements actually accelerates development. Not all the requirements development effort should be allocated to the beginning of the project. Projects that follow an iterative life cycle model will spend time on requirements during every iteration.

You can use a commercial estimating tool that suggests feasible combinations of development effort and schedule. These tools let you adjust estimates based on factors such as the skill of the developers, project complexity, and the team's experience in the application domain.

If you don't compare your estimates to the actual project results and improve your estimating ability, your estimates will forever remain guesses.

A project manager who can justify an estimate based on a well-thought process and historical data is in a better bargaining position than someone who simply makes his best guess. Include contingency buffers in your schedule and budget to accommodate some requirements growth. Don't let your estimates be swayed by what you think someone else wants to hear. Your prediction of the future doesn't change just because someone doesn't like it.

Major planning mistakes include overlooking common tasks, underestimating effort or time, failing to account for project risks, not anticipating rework, and deceiving yourself with unfounded optimism.

Keep your specifications free from implementation bias except when you have a compelling reason to intentionally constrain the design. The time you spend translating requirements into designs is an excellent investment in building high-quality, robust products.

The simple act of thinking through how you'll verify each requirement is itself a useful quality practice. Testing against requirements must be performed at every level of software construction, not just the end-user level.

Strive for a sensible balance between rigorous specification and off-the-top-of-the-head coding that will reduce to an acceptable level the risk of building the wrong product.

Next post:

• Software Requirements - Part 5