What is requirements management and why is it important? The world of requirements management has developed significantly in the last decade or so and has increasingly become one of the corner stones of successful software and systems engineering projects. We have been discussing various aspects of the domain from a best practices perspective and how tools can help managing your requirements efficiently and effectively.
Starting today we will discuss various aspects of the requirements management discipline at a bird’s eye view level. These are meant to be introductory in nature and also intend to serve as refreshers for those who are already in the field. The domain and best practices have developed to an enormous level of sophistication that; it is difficult to cover everything in a set of blog posts. However we intend to make these posts as a quick reference and starting point for you to think seriously about the domain.
Have you heard about the Gaudi’s unfinished Cathedral or Airane 5 explosion? The former one is a hundred year project still under progress which couldn’t be finished because of unclear and changing requirements and the latter one resulted in over $7 billion loss when the rocket exploded on its first voyage due to a software error; specifically floating point number error. The importance of requirements management can be established from three unique perspectives – project overshoot and thus missing the market opportunity due to unclear and changing requirements; project failures due to unmet or misunderstood requirements and finally cost burden due to errors and missed requirements found late in the development cycle.
In a classic IEEE Spectrum article, Robert N. Charette writes about “Why Software Fails”. Among the top reasons for failure of software projects are poor definition of requirements, poor management of risk, communication failure among stakeholders and increasing complexity of projects. Many research firms (Standish Group’s CHAOS report, Gartner, CMU-SEI) and academicians (A. Davis, Robert B.Grady, Steve Easterbrook) have studied and quantified the failure rates of software projects (for example, in the above IEEE article Robert opines that 40-50% of software development time is spent on rework and cost of fixing a bug in the field can be as high as 100 times compared to when fixed at development stage). In all of them, the preliminary reasons for failures or overshoots are ineffective management of requirements.
So what exactly is requirements management?
Before moving to requirements management, let’s understand what a requirement is? A requirement can be anything from an abstract need to a well drilled down implementation detail of a system. Essentially it can be considered the detailed view of a need under consideration. IEEE Standard Glossary of Software Engineering Terminology defines a requirement as a condition or capability needed by a user to solve a problem or achieve an objective; or a condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents; or a documented representation of a condition or capability as in former two. Thus what a requirement essentially represents depends on to whom we are talking to – it could be the need to a client; a business requirement for customers; a system requirement for vendors or a specification for a developer and tester. We will come to the different types of requirements later. Requirements Management can be considered the management of requirements essentially from when a customer provides the needs or a product development process is started. It includes managing the definition, elaboration and changing requirements during the development cycle and systems development. Peter Zielczynski, a requirements management expert defines the following major steps in requirements management:
- Establishing a requirements management plan
- Requirements elicitation
- Developing the Vision document
- Creating use cases
- Supplementary specification
- Creating test cases from use cases
- Creating test cases from the supplementary specification
- System design
Zave (Classification of Research Efforts in Requirements Engineering. ACM Computing Surveys (1997)) defines Requirements Engineering as “the branch of software engineering concerned with the real-world goals for, functions of, and constraints on software systems. It is also concerned with the relationship of these factors to precise specifications of software behavior, and to their evolution over time and across software families.” While in practical terms, this could be considered same as requirements management, we can say requirements engineering addresses various aspects of requirements development; requirements management is the set of processes in systems and software engineering that interfaces with requirements engineering. We will try to delve into more details in another post when we consider V&V (Verification & Validation) model.
Next time we will discuss how to write good requirements and types of requirements.
About the Author
