In my first article, I described the importance of having a systems engineering (SE) process to manage and direct the technical aspects of a project. I provided a very brief overview of what SE addresses, what the costs are of having (and not having) an effective SE program in place.In this article, I will discuss one of the most important aspects of the SE process: requirements definition. This is arguably the critical piece of the SE process that can make or break a project. It defines what is going to be built, manages expectations of the end users and stakeholders, and places a boundary around the effort. It also provides an objective set of criteria to evaluate whether or not the delivered system or systems meet everybody's expectations.Please be aware, this article is not a comprehensive discussion of the requirements process. Rather, it's designed to provide a limited discussion of the process, how requirements should be categorized and structured, and why this basic understanding is so important in defining a project. There are many books, Internet resources, and the International Council on Systems Engineering INCOSE website that can provide the details for the requirements definition process.What are Requirements?Wikipedia has a very good definition of a requirement: it is a statement that identifies a necessary attribute, capability, characteristic, or quality of a system for it to have value and utility to a customer, organization, internal user, or other stakeholder. A specification is a specific set of requirements that are satisfied by a material, design, product, or service.Requirements are typically organized in a way that address very high level needs to very specific needs. Requirements can also specify the processes needed for realization of the deliverable. This set of requirements defines what is being built and how it fits into the overall enterprise. For example, at the highest level, requirements can define mission, operational objectives, and management. As the specificity increases, requirements can be categorized by operational scenarios, use cases, and behaviors. Finally, at the highest level of specificity, we can include Performance, the "ilities" (i.e., Reliability, Availability, Maintainability), Security, and Safety.We can also have orthogonal requirements that focus the "how:" how are we going to implement the requirements. These focus on management of the effort and will be discussed in the next section.Taxonomies of RequirementsRequirements are organized by taxonomy. At the highest level, there are functional requirements, which defines what the systems does and how it does it, and non-functional requirements, which covers everything else, which are generally the management aspects of how the system will be designed, built, tested, and delivered. These can also include management constraints, regulatory requirements, and technical standards, and quality of service requirements.How the requirement taxonomy is constructed should be based upon some known standards, such as those from INCOSE, IEEE, and the International Institute of Business Analysts, which I offer below:
Business requirements: High-level statements of the goals, objectives, or needs of an organization. They usually describe opportunities that an organization wants to be realized or problems that they want to be solved. Often stated in a business case.
User (stakeholder) requirements: Mid-level statements of the needs of a particular stakeholder or group of stakeholders. They usually describe how someone wants to interact with the intended solution. Often acting as a mid-point between the high-level business requirements and more detailed solution requirements.
Functional (solution) requirements: Usually detailed statements of the behavior and information that the solution will need. Examples include formatting text, calculating a number, modulating a signal. They are also known as capabilities.
Quality-of-service (non-functional) requirements: Detailed statements of the conditions under which the solution must remain effective, qualities that the solution must have, or constraints within which it must operate. The "ilities" are examples of QoS requirements: Reliability, Testability, Maintainability, and Availability.
Management (non-functional) requirements: These requirements include project methodology (e.g., Scrum, Waterfall, Spiral, etc.), support deliverables such as project management plan, systems engineering plan, test plans, monthly progress reports, etc.
Implementation (transition) requirements: Usually detailed statements of capabilities or behavior required only to enable transition from the "as is" state of the enterprise to the "to be" enterprise. Examples include: staffing, training, change management, and data migration.
Characteristics of RequirementsIn order for requirements to be effective, they need to have certain characteristics. In this section, I offer some key characteristics that are important to evaluate requirements against:
Unitary: The requirement addresses only one thing.
Complete: The requirement is fully stated with no missing information
Consistent: The requirement is consistent with the other requirements, does not contradict other requirements technical standards, and design documentation.
Realistic: The requirement must be feasible with the available technology, cost, and schedule constraints, and acceptable risk.
Traceable: The requirement must be traceable back to the business and/or mission needs.
Measurable and verifiable: The requirement must be stated unambiguously; with measureable criteria for insuring the deliverable can be tested against the requirement. This is especially important when dealing with quality of service requirements. In the case of more qualitative requirements such as user experience (UX and human factors, it is important to consider metrics of human performance against the interface such as time to react, maximum error rates, etc.
Importance/prioritization: Requirements need to be ranked from critical to non-critical or "nice-to-have." This provides needed information to the project manager and the development team on the implantation sequencing in the project plan. Another aspect is risk/reward: It is often useful to implement low-risk high reward requirements early on, especially when using Agile or Spiral development approaches.
Documenting RequirementsThere are numerous software tools available for requirements management, from IBM/DOORS at the high end to simple Excel spreadsheets. Whatever method is used, it is necessary to employ a requirements engineer who is familiar with requirements documentation, systems, and methods. One method I have successfully employed is a requirements wiki. The wiki provides an attributable tool for requirements management, including progress reporting, changes, issues, and recommendations for improvement.Requirement PitfallsThe biggest issue with requirements management is scope creep: this is the tendency to add new requirements during development. In extreme cases, new requirements are added faster then they can be realized, which means the project starts to move backwards. Besides the fact the project is at risk of never being completed, adding new requirements adds to costs, creates frustration with the development staff, and complicates implementation. For example, if new requirements are added after a significant amount of development is completed, it often means throwing out work that has been delivered and starting anew. It also dramatically increases the risks of interface problems and unanticipated consequences.The requirements process can also create pitfalls. The process for collecting, evaluating, vetting, and managing requirements can be influenced by outsiders with agendas who may want to influence, or worse yet, sabotage the project. A good example of this was the F-16 program, which was perceived as a threat to the F-15 program, with the latter surreptitiously injecting new requirements into the former, to overburden the project with complexity, weight, and capabilities. As a result, it is extremely important the requirements process be rigorous, independent, and managed buy a strong leader who can say "NO!" when these pitfalls occur.ConclusionsThe requirements process and the proper definition of requirements for a system are critical for increasing the odds of a project's success. The growing number of failed projects can be directed attributed, in whole or in part, to an ineffective requirements processes, which resulted in poorly defined requirements, scope creep, or political gamesmanship in the definition and prioritization of the requirements. As a result, getting an expert systems engineer who is well versed in the requirements definition process is absolutely necessary to mitigate the risk of project failure.
No comments:
Post a Comment