Follow Us:

Eliciting, Collecting, and Developing Requirements

Definition: Requirements define the capabilities that a system must have (functional) or properties of that system (non-functional) that meet the users' needs to perform a specific set of tasks (within a defined scope).

Keywords: agile, elicitation, elicitation techniques, project scope, requirements, requirements attributes, requirements elicitation, root cause, scope, spiral, stakeholders, user requirements, users, waterfall

MITRE SE Roles & Expectations: MITRE systems engineers (SEs) are expected to be able to elicit business, mission, and operational needs from operational users and other stakeholders. They are also expected to be able to analyze, integrate, and transform these needs into system requirements as well as facilitate stakeholder engagement on and resolution of requirements. MITRE systems engineers are expected to be able to tailor the principles of requirements elicitation to different development methodologies (waterfall, spiral, agile, etc.).

Overview

After operational needs are assessed and the concept of operations (CONOPS) and high-level concept definition are completed,  the next step—and typically the first task on development projects—is to discover, elicit, collect, define, and analyze requirements. Requirements will cover various aspects of a capability or system—user needs, behavioral, quality, implementation, etc. Given these, the systems engineer will analyze, transform, and integrate users' needs into system requirements. See the Concept Developmenttopic in this Guide for more information on the first steps in development projects.

Figure 1 highlights a typical process for collecting and evaluating requirements. Allocating sufficient time and effort to the requirements process to build a strong foundation for the effort has proven to be cost effective in the long run.

Figure 1: Overview of Requirements Collection and Change Processes

The figure represents typical sequencing of many of the activities and milestones that are part of the requirements collection and management processes. Activities may be added, modified, deleted, and their sequences changed, depending on the scope and type of project or task. Generally, sub-tasks within a larger project focus on fewer activities and may have different stakeholders and finer grained criteria for success than the project itself.

The process followed by the systems engineer depends on the project's complexity and implementation methodology: waterfall, spiral, agile, etc. Studies have shown that accurate, well-defined, and clearly stated requirements reduce development time and effort and are essential to the quality and success of the final product. Users provide functional and non-functional requirements, which form the substrate on which the project is built. Functional requirements are associated with the capability/application need to directly support the users' accomplishment of their mission/tasks (features, components, etc.). Performance requirements are those that are typically implicit and technical in nature that emerge as system requirements to satisfy the users' functional needs (e.g., quality of service, availability, timeliness, accuracy). Systems engineers work closely with users to observe, discuss, and understand the user requirements.

Waterfall model: Projects using the waterfall model progress through a series of phases/milestones in a linear fashion, with the first phase dedicated to the requirements task. The first milestone occurs when a complete set of functional, performance, and other requirements has been documented, validated, and approved by the user. Stabilizing requirements early in the project's life cycle facilitates subsequent project work and significantly reduces risk. This type of model can be feasible in the increasingly rare situations when the customer mission or business is fairly static, the need is focused, and the user environment is stable.

Spiral model: Each cycle or level in the spiral model includes several activities found in various phases of the waterfall model. This model is used to reduce project risk incrementally. At the end of each cycle, stakeholders analyze risks and develop appropriate risk reduction strategies for use at the next level. The systems engineer collects, documents, and updates requirements before the project starts and after each cycle. The requirements may be known up-front, but spirals are used to get capabilities to the users quicker, or the requirements may not be completely known up-front, but the basic operational needs and concepts are known, so projects can begin and allow the future evolutions' requirements to be determined over time. The first milestone usually occurs early in the spiral under these conditions: requirements for the spiral are complete and agreed to by the user concurrently with an operational concept, plans, design, and code.

Agile model: The agile software development model does not require detailed documentation and design at start-up but does require flexible systems engineering support during the project. Typically, small efforts are performed and the set of requirements is focused on small, specific capabilities with the users and developers teaming to work the interplay of requirements and capabilities together. "Agile" emphasizes very short cycles, substantial user collaboration from start to finish, close team work, constant communication among participants, the ability to adapt to change, and incremental development. The goal is to quickly develop working functional software that meets the users' needs, not produce detailed requirements or documentation. The systems engineer may wear several hats in an agile environment by providing support as needed, for example: identifying emerging requirements that may violate standards and regulations; analyzing, then documenting requirements as they evolve; calculating metrics; and writing functional specifications, test cases, meeting minutes, and progress reports.

Using multiple models: More than one model can be used during a project's development. Regardless of the particular model, all approaches should include requirements elicitation in some form. The activities in the practices below are often associated with the waterfall model but many are modified for use with other models as well. The systems engineer may change, reorder, repeat, or omit activities on the list, depending on the project type, complexity, methodology, and environment. A structured approach can help guide the requirements collection process from the first (i.e., "kick-off") meeting between the systems engineer and stakeholders until requirements are baselined and approved. These guidelines are applicable and adaptable for requirements collection on large and small systems, new systems, and existing systems that are being updated or replaced. Requirements may also evolve over time due to mission changes, business environment changes, etc. The requirements must be managed throughout the life cycle to ensure the needed capabilities are being created and delivered to accommodate changes.

Challenges exist today with the requirements engineering process—frequently, sufficient time is not allocated to understand operational concepts and thus the requirements associated with them; requirements are specified, not managed to accommodate changes; requirements are not revisited often enough to further assess trade-offs that users would consider in order to manage schedule and costs. However, a good requirements process can provide a strong foundation for satisfying user needs.

Best Practices

• Apply good interpersonal skills. Such skills are always an asset, but they are a necessity when eliciting requirements. When systems engineers are objective and open-minded and have good listening skills, their relationships with users and other team members are productive. Their ability to effectively communicate project status and resolve issues and conflicts among stakeholders increases the likelihood of the project's success.
• Think broadly. A systems engineer with broad knowledge of the enterprise in which requirements are being developed (whether for a system, service, or the enterprise) adds value and may be able to identify solutions (e.g., process changes) that are cost effective.
• Be prepared. Collect data and documents that provide context for the project. Review data generated during enterprise and concept analysis, and review any business case and decision briefings for the project. Become familiar with historical information, organizational policies, standards, and regulations that may affect requirements and impose constraints. Gather information on previous projects, successful or not, that share characteristics with the new project. Review their system specifications and other technical documents, if they exist. The systems engineer may derive "explicit' or "implicit" lessons learned and requirements from data on the previous project. Find out whether there are descriptions of current operations, preferably an approved concept of operations (see the Concept Development topic in this Guide), and any documented issues. Some of this material may identify potential stakeholder types and subject matter experts (SMEs) that may be needed. Draft a requirements collection plan, estimate resources needed, and consider the types of tools that would be appropriate on a project using this particular methodology. Identify potential risks that might arise during the requirements collection process (e.g., key stakeholders are unavailable due to time constraints) and plan risk mitigation strategies.
• Identify and manage stakeholders. A single individual or organization often initiates a project. Inevitably, the new project will affect other individuals, organizations, and systems, either directly or indirectly, thereby expanding the list of stakeholders. Stakeholders' "roles" are: the executive sponsor funding the project and possibly a contributor to requirements; primary stakeholders and others providing functional and performance requirements; stakeholders affected by the project indirectly (e.g., interfacing businesses and operations) who may contribute requirements; SMEs (e.g., managers, system architects and designers, security staff, and technical and financial experts); and stakeholders who must be kept in the loop (e.g., business analysts, legal and financial experts). As needed, stakeholders should be asked to review, comment on, and approve requirements for which they are responsible. Set up a process for communicating with stakeholders (e.g., meetings of all types, formal presentations, bi-weekly reports, and email).
• Determine the root cause of the problem. Before requirements collection starts, it is critical that the systems engineer answers the question: what is the real need that the project and its product are intended to address? The systems engineer must tread carefully but resolutely in the user's environment to uncover the real vs. perceived needs. Examining some of the concept and operational needs information can help with the analysis. The next vital question is: have all stakeholders agreed on a clear and unambiguous need statement that is consistent with the business case? The systems engineer's ability to state the problem in an implementation-independent manner is extremely important. Customers may find it difficult to accept the fact that their solution to their perceived problem is not viable, or that other options should be explored.
• Define capability scope. The systems engineer generates capability scope that provides a framework for the project and guides the requirements collection process. The capability scope is usually the first source of information about the project available to all stakeholders before the project gets underway. It is reviewed by stakeholders and approved by the customers. The systems engineer's goal is to elicit and discover all requirements and ensure that each is within the boundaries described in the scope. This criterion is used to evaluate requirements' changes throughout the life cycle. Scope assessments are not limited to the requirements phase. They are often used to cover project activities from launch to completion, specific activities (e.g., pilots and testing), and for small tasks within larger projects. Capability scopes are generated as needed, for example: before or after requirements collection, or for inclusion in a request for proposal, work breakdown structure, or statement of work. Other documents, such as PDDs (project definition documents) and SOOs (statements of objectives) often serve the same purpose as capability scopes.

Capability scope documents describe the'who, what, when, and why' of the project and include information needed for project planning. Capability scope documents cover most of the topics below. Some top-level information for the scope can be found in the operational needs and concepts information from the user community.

• Purpose: What problem is the customer trying to solve? What does the customer need and want? What will this project achieve?
• Value Proposition: Why is this capability justified?
• Objectives/Goals: High-level goals that can be measured
• Sponsor: Who is paying for the capability?
• Customers: Who will use the results of the project?
• Scope of Project: Activities and deliverables included in this project
• Out-of-Scope: Activities and deliverables not included in this project
• Interfacing: What are the interfacing capabilities, systems, or user communities that will touch this project?
• Major Milestones: Events denoting progress in the project life cycle (e.g., completion of key deliverables or important activities)
• Dates: When are deliverables due? What are the planned milestone dates?
• Critical Assumptions: Assumptions underlying plans for conducting and completing the project
• Risks: Potential changes in the project's environment or external events that may adversely affect the project
• Issues: Issues that have already been identified for this project
• Constraints: Rules and limitations (e.g., time, resource, funding), that may dictate how the project is carried out
• Success Criteria: Outcomes that meet requirements, targets, and goals and satisfy the customer
• Discover and elicit requirements from all relevant sources. The systems engineer collects requirements from many sources including, but not limited to: experienced and new users, other stakeholders, SMEs, managers, and, if necessary, the users' customers. Operational users are key contributors because they provide some or all requirements for the system's functional and performance capabilities and user interface. Their inputs are essential to delivering a product, system, or service that helps improve their efficiency by enabling them to easily access the data they need when they need it. The systems engineer elicits requirements directly or indirectly based on users' informal narratives, observing the user environment, or capturing their responses to targeted questions. The systems engineer wants to learn about the operational users' environments and needs a lot of information for that purpose, such as: detailed descriptions of users' daily, weekly, monthly, and other periodic tasks; documentation (e.g., training manuals); reporting requirements and examples of written reports; preconditions and/or triggers for taking various actions; workflows and sequencing of specific tasks they perform; external and internal rules they must follow including security requirements; interactions with other operational users, staff members, systems, and customers; type and frequency of problems they encounter; and, overall, what does and does not work for them currently. Users' responses to questions such as "describe your ideal system" may open up areas not previously considered. The systems engineer can confirm requirements collected and possibly uncover new ones if given the opportunity to directly observe users doing their jobs. Passive observation is often time well spent.

The systems engineer consults with SMEs to ensure that system, security, and operational requirements are complete and feasible; the systems engineer also brings attention to and incorporates into the requirements, government and other regulations that must be taken into account during the program. Project size and type, complexity, schedule, number of interviewees, and locations are factors that will determine techniques best suited to eliciting requirements for this project. Techniques include direct observation, one-on-one and/or group interviews, brainstorming sessions, focus groups, surveys and targeted questions, and prototyping. Joint (users, developers, integrators, systems engineering) requirements gathering sessions are frequently one of the most powerful techniques for eliciting requirements. When systems engineers analyze related documents, system interfaces, and data, they are likely to discover new requirements. Reverse engineering may be needed to uncover requirements for legacy systems that are poorly or not documented. Collection activities proceed to the next life cycle step (e.g., beginning system design) when users confirm that implementation of the current set of requirements will meet their needs, and project staff agrees that they can build a viable product based on these requirements. However, with many changes in the stakeholders' operations, a continuous requirements collection and refinement effort is needed to ensure initial requirements are captured and future capability assessments are started by examining the next evolution of requirements due to change, increased certainty in need, or a phased implementation approach.

• Document requirements' types and attributes. When there are many requirements, categorizing and organizing them can be daunting. As the process matures, requirements' attributes must be documented and kept up to date to remain traceable during testing, validation, and verification. This process helps systems engineers and others identify duplicate, missing, and contradictory requirements. Attributes most often tracked are these requirements: ID (number), description, type (e.g., functional, non-functional, performance, explicit, derived, system, operational), priority (e.g., mandatory, desirable), phase (threshold or objective), level of risk, business value (e.g., high, medium, or low), source (e.g., stakeholder, regulation, interface specification), rationale for including the requirement (e.g., improves performance), name of implementer, level of effort, status (e.g., proposed, approved, verified, closed), and, later, release number/release date.
• Model requirements for validation. Stakeholders are frequently asked to review documents that include those requirements for which they are responsible. Stakeholders sometimes need help interpreting requirements; they also expect and are entitled to receive clear explanations of outcomes when they are implemented. Explanations can be facilitated by creating "as is" and "to be" process flows, activity diagrams, use cases, entity relationship diagrams, workflow models, and flowcharts. Models can also be in the form of prototypes or experiments to provide a limited functioning context where users can try out various alternatives, and together the user and systems engineer can assess the requirements (see the SEG article Special Considerations for Issues of Uncertainty: Prototyping and Experimentation in this topic area). Visual aids that are focused on these areas tend to engage the stakeholders' interest. Models show stakeholders how the requirements they contributed represent their statements and goals, and are complete and consistent. Agreeing on the meaning of each requirement and its effect on the final product may call for several iterations of discussions, modifications, and reviews by different groups of stakeholders. Putting everyone on the same page takes time. The systems engineer updates requirements when changes are made at reviews and meetings and tracks issues (e.g., action items) and conflicts. When conflicts cannot be resolved, the systems engineer brings them to the customer's or sponsor's attention, using other levels of MITRE management, as appropriate.
• Prioritize requirements. As the collection process winds down, stakeholders are asked to assign a priority to each requirement. There may be differences of opinion about which ones are mandatory, critical, desirable, or optional. It is up to the systems engineer to define each priority (e.g., needs vs. wants), point out inappropriate priorities, and suggest changes based on knowledge of this particular project and past experience. Prioritization ends when stakeholders reach agreement. Getting stakeholders to reach agreement can be difficult. A best practice is to develop and put in place a stakeholder contention adjudication protocol early in the requirements elicitation process. Identifying critical requirements is particularly important when evaluating competing systems and commercial-off-the-shelf products. They are also used to evaluate deliverables at various milestones or evolutions, and, in projects developed incrementally, help determine which requirements are included in each phase.
• Work toward getting final agreement from contributing stakeholders. At the end of the requirements collection process, plan to hold a face-to-face requirements review meeting attended by stakeholders that contributed requirements. Include project team members if possible. Often, last-minute requirements changes are needed to reach consensus that they are complete and correct. At that point, requirements are considered "baselined," "locked," or "frozen." But be careful—flexibility is needed throughout the life cycle to ensure that system development and implementation does not try to meet the exhaustive set of requirements when earlier delivery or perhaps reduced costs could be achieved (e.g., why the prioritization step is very important).
• Document requirements for final approval. The requirements document or specification will dictate much of the project's future work. Before the specification is approved, ask reviewers that know the characteristics of "good" requirements to review it. Good requirements are unique and uniquely identified, necessary, consistent, complete, traceable, testable, implementation-free, attainable, unambiguous, and verifiable. It may be necessary to modify or delete "bad" requirements and their dependents. Dependent requirements are associated requirements, many times implicit or emerging from a functional requirement (e.g., need for data would drive a technical need for some form of database/repository). Final approval is made by the executive sponsors or one of the customers. Inevitably, some requirements in the specification will be misinterpreted by implementers, many of whom may be seeing them for the first time. To avoid or minimize misinterpretations, the systems engineer, optimally together with the user community, must be given time to go over the approved specification with designers, software engineers, quality assurance staff, testers, and others to answer questions.  As soon as possible, a close community of users, systems engineers, designers, developers, integrators, and testers should be formed and maintained.
• Capture lessons learned. Although MITRE internal projects differ from MITRE direct customer projects in many ways, there are commonalities when it comes to requirements and lessons learned. When a project ends, project members, including managers, are encouraged to document their experiences, good and bad, using the LAMP (Lessons About My Project) template. A facilitator conducts a "Lessons Learned Review" with project participants and uses the LAMP to identify best practices and processes that need improvement. The LAMP site provides many practical case examples of eliciting requirements.

Even when the requirements are good, complete, and correct, as a project is launched, changes are inevitable. Experience has shown that adding, modifying, and deleting requirements after a project is underway greatly increases cost. A formal requirements management process will help control cost, avoid requirements creep, and ensure end-to-end traceability. However, changes do occur and flexibility is needed to manage the changes while concentrating on delivery of capabilities to users as soon as feasible.

Related articles in this Guide include Analyzing and Defining Requirements and Stakeholder Assessment and Management.

References & Resources

1. Ambler, S.W., September 1, 2005, "Seeking Stakeholders," Doctor Dobbs Digest.
2. Ambler, S.W., September 16, 2008, "Strategies for Addressing Non-Functional Requirements," Doctor Dobbs Digest.
3. Ambler, S.W., October 1, 2005, "Requirements Wisdom," Doctor Dobbs Digest.
4. Association for Computing Machinery, ACM On-line Course on Eliciting Requirements, viewed March 3, 2010.
5. Bahill, T., "Eliciting Requirements in Use Cases and What is Systems Engineering? A Consensus of Senior Systems Engineers," viewed March 3, 2010.
6. Bruegge, Bernd, A.H. Dutoit, and A.A. Dutoit, October 1999, "Object-Oriented Software Engineering: Conquering Complex and Changing Systems," Pearson Education.
7. Florence, A., April 2002, "Reducing Risks Through Proper Specification of Software Requirements," CrossTalk: the Journal of Defense Software Engineering.
8. Florence, A., October 2003, "Requirements Validation and Verification," QAI Journal.
9. Florence, A. and W. Bail, 2005, "Effective Requirements Practices," The MITRE Corporation.
10. Gottesdiener, E., March 2008, "Good Practices for Developing User Requirements©," CrossTalk: The Journal of Defense Software Engineering.
11. The MITRE Corporation, "ISIS Systems Technology and Engineering Projects (iSTEP)," viewed March 3, 2010.
12. The MITRE Corporation, "Lessons About My Project (LAMP)," viewed March 2, 2010.
13. Nuseibeh, Bashar and Steve Easterbrook, 2000, Requirements Engineering: A Roadmap, Department of Computing, Imperial College of Science, Technology & Medicine, London, UK.
14. Robertson, J. and S. Robertson, February 2006, Volere Requirements Specification Template.
15. West Pole, Inc., 1996-2005, Use Case and Interviewing Techniques for Focused Requirements Capture.