Managing Requirements your way (Part 1)
Intro
In this Blog series I will try to reveal new ways to improve your requirements process – regardless of your starting point or requirements process. In this post I will define the requirements process and outline the various capture methods available today. In future posts we’ll look at the pros and cons of various common approaches used by organizations today to manage requirements, from the simplest manual process, to agile processes used in software development organizations, through to the most formal requirements process – and in each case, outline ways Polarion Requirements can be leveraged to better each process method.
Finally, for organizations that are approaching the requirements discipline for the first time, or who have a requirements process that is in-between the processes we’ve described – not too agile or not formal – I will share some recommended best practices for requirements management that we at Polarion have cultivated through our own experience in developing software, all of which can be easily enabled with Polarion Requirements or Polarion ALM Enterprise and implemented within any organization.
Why requirements?
In computing science terms, requirements management remains an immature discipline. While best practices surrounding the requirements management process and tooling continue to advance, there is tremendous opportunity for organizations to tighten up their product development process through greater maturity of the requirements management discipline.
Failure to properly define and manage requirements is often at the root of software project and product failure. It is a business reality that customers and management rarely know, or can describe in exact terms what they want at the end of the day. And too often, these same business sponsors will change their mind midstream – causing requirements to change. The impact of change even early in the project causes a downstream ripple effect, impacting project schedules, deadlines, delivery dates, and staffing commitments.
The ultimate goal of requirements management is, at the end of the day, to ensure that the final product meets the needs of the business. While this seems like a simple task, the process of articulating business needs or specifications, especially for complex products or software applications, is immensely difficult and requires significant elicitation and communications expertise plus advanced technologies to absorb, and manage detailed requirements and groups of requirements through to successful product/project delivery.
Organizations are individual in their approach to requirements management. Some companies and teams continue to rely upon manual processes – opting for a simple, tool-free approach that costs nothing and presents no learning curve. Others, such as a software development team who have embraced an agile development process, such as SCRUM and XP, demand a more fluid and transparent requirements process and lightweight tools that allow for iteration and frequent change. And finally, there are organizations with complex product development processes or in regulated industries that need a highly formalized and rigid requirements process and significant tooling support.
Requirements Management Defined
Requirements management is formally defined in computing terms as the process for eliciting, documenting, analyzing, prioritizing and agreeing upon requirements, complemented by the control and communication of change to requirements through the project lifespan. Let’s expand on that definition, but first let’s take a look at the various requirements formats and capture methods used by organizations today. Then we’ll take a closer look at the various phases of the requirements lifecycle.
Requirements Formats
Requirements can take many forms, from very simple to extremely complex, depending on the business, the industry within which the business operates and the complexity of the product under development. Frequently, requirements are expressed in the form of a single statement. An example of single might be found in a user requirement that says “the car must burn less than 31 liters of fuel per 100 kilometers, or a system requirement that indicates “the processor should be at least 3 MIPs”.
Sometimes, requirements can be embodied in a set of statements that provide a more expanded amount of detail into the development of a system. An example of a set of requirements might be a scorecard that outlines pre-conditions, post-conditions, rationale, description, originator, fit criteria and prioritization.
A requirement may take the form of a prototype, such as a user interface prototype, a physical prototype (such as in the case of a hardware device) or a design prototype. Or it may be expressed in the form of a UML, SysML, entity/relationship model or a drawing.
And the final and most detailed form of requirement is a specification, which is a much larger document that outlines the intended behavior of the system or product, including use cases outlining detailed functional requirements, non-functional requirements such as quality standards or design constraints, as well as diagrams, pictures, operational scenarios and any other detail that provides elaboration on the product to be developed.
Whether contained within a single line statement, or part of a large, elaborate specification, requirements should be “good” as defined by the following criteria: complete, correct, feasible, necessary, prioritized, unambiguous and verifiable.
Requirement Capture Methods
The format of requirements is one consideration in the early requirements process. The other consideration is the method for capturing the requirement. While expression of requirements in various forms is often pegged to the culture of operation of the business, and the industry in which the business works, the chosen requirements capture method has much more to do with the relative maturity of the organization – and recall if you will, requirements management is still a very immature and poorly understood discipline outside of a few highly technical industries.
The vast majority of organizations today still use static Microsoft Office Word documents or Excel spreadsheets to capture and manage user and system requirements, for the simple reason that the tool is ubiquitous and easy to use. Smaller organizations with shallow pockets will also use Word documents as a capture mechanism due to a lack of resources and ability to invest in more dedicated or specialized RM tools. However, for larger projects, where there are multiple stakeholders, long ranging projects spanning months or even years, and where there is much iteration of requirements, this static format can falter.
Phases of the Requirements Lifecycle
There are several ways of breaking down the requirements management process. The most widely recognized stages include:
Elicitation
In the elicitation phase, requirements are gathered through various means, including questionnaires, interviews, brainstorming, workshops such as joint application development (JAD) sessions, user observation, mining of a customer support, feedback or issues management system. Requirements elicitation is highly subjective, and tricky to do right. As noted earlier, business stakeholders and customers are rarely able to accurately articulate their needs in order to accurately define a complete set of requirements from the outset.
Discussion
Because elicitation can be a subjective and imprecise stage in the process, requirements gathered through elicitation are then further refined by stakeholders in the process, an approach that may include further technical research, research on the competitive marketplace, as well as scoring, correlation and weighting of requirements to assist in prioritizing and sequencing.
Approval
In the approval phase, some organizations generate a requirements approval document which is circulated or conveyed via workflow to stakeholders for approval, agreement and sign off. This approval by stakeholders is a critical gate to the initiation of work. At this stage, everyone agrees that the requirements are aligned to business need, and will yield the desired product.
Verification
Verification early in the development process is critical, to ensure that solution design matches the requirements and the business need. Verification can be performed through a questionnaire, walkthroughs, or various forms of testing.
Verification against requirements is a stage in the requirements process that can be directly tied to cost savings – corrections to faulty requirements early in the development process can significantly reduce testing costs at later stages, and costs exponentially less in terms of resources and time. Depending on the product in question (i.e. medical device, or automotive vehicle) proper verification of requirements can actually contribute to human health and safety, by reducing risk due to mechanical or software error.
Acceptance
Defined acceptance criteria are a measure used by organizations to ensure that the final project or product meets the requirements of the business, stakeholders and customers. A requirements acceptance procedure and associated documents can form the initial baseline for a specific release. The definition and measure of acceptance criteria is a fairly sophisticated step in the requirements process that lowers the risk of rejection by the customer. In the acceptance phase, the customer uses these acceptance criteria to either accept, or reject the product.
Change
Products and needs evolve, and so do their requirements. Change to requirements may arise mid-stream during a project’s evolution, or after the release – in either situation, an organization must be equipped and able to manage, track and communicate change to requirements under any condition.
What’s next
In the next post I will talk about the Manual Requirements Process (I mean the process of managing requirements “by hand”) and we will go through some easy steps to improve it.
Editor’s Note:
Stefano Rizzo is VP for Product Management at Polarion Software. He oversees the strategic development of Polarion’s software products. You can read his profile at http://www.polarion.com/company/people/index.php.
