Download Eliciting, Collecting, and Developing Requirements and more Lecture notes Information Technology in PDF only on Docsity!
https://www.mitre.org/publications/systems-engineering-guide/se-lifecycle-building-blocks/requirements-engineering/eliciting-collecting-and-developin… 1/ 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 and 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 to facilitate stakeholder engagement on and resolution of requirements. MITRE (SEs) 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,
https://www.mitre.org/publications/systems-engineering-guide/se-lifecycle-building-blocks/requirements-engineering/eliciting-collecting-and-developin… 2/ define, and analyze requirements. Requirements cover various aspects of a capability or system—user needs, behavioral, quality, implementation, etc. Given these, SEs will analyze, transform, and integrate users' needs into system requirements. For more information on the first steps in development projects, see the SEG's Concept Development topic. 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.
https://www.mitre.org/publications/systems-engineering-guide/se-lifecycle-building-blocks/requirements-engineering/eliciting-collecting-and-developin… 4/ When a project's outcome heavily depends on the success of the software component, lines between the project’s strategy and the software’s implementation methodology sometimes blur. The Software Development Life Cycle (SDLC) is a process methodology for software development. Models using SDLC are waterfall, spiral, and agile. The model selected depends on factors such as the project's size, complexity, aims, and objectives; the degree to which requirements are well understood and articulated up front; the stability of the environment in which the system will function; and, most important, the customer’s needs, availability during the project, and risk tolerance. A very important consideration is the project’s timeline. Waterfall model: Relatively low-risk projects use the waterfall model and progress through a series of phases/milestones in a linear fashion over time. The initial phase is often the requirements task. The first milestone occurs when the user and stakeholders have documented, validated, and approved a complete set of functional, performance, and other requirements. Phases that follow are design, implementation, testing, integration, operations, and maintenance. Each phase is formally documented, validated, and approved. Failure to meet a milestone may require repeating one or more of the preceding phases until deficiencies are corrected. The SE is expected to maintain the requirements document to
https://www.mitre.org/publications/systems-engineering-guide/se-lifecycle-building-blocks/requirements-engineering/eliciting-collecting-and-developin… 5/ reflect changes that may be made during these phases. This type of model is feasible when the customer mission or business is fairly static; the need is focused; the end user’s environment is stable; risks associated with cost, schedule, security, and other important factors are low; and significant changes in requirements during the project are highly unlikely. It is prudent to inform the customer during requirements collection, especially before final approval, that requirements’ changes in projects using the waterfall model can be costly. Spiral model: When starting a project without a complete set of documented requirements, the spiral model may be selected to reduce project risk incrementally as well as to deliver the requested capability more quickly. When requirements are partially known but the basic operational needs and concepts are well understood, the project can begin with the expectation that remaining requirements will evolve over time. Each cycle or iteration in the spiral model follows the same processes: define objectives, consider alternatives, recognize constraints, and generate a usable prototype. The initial loop starts with the CONOPS and life-cycle planning. Successive loops include high-level requirements, software requirements, preliminary design, detailed design, development, and test. The model works by building progressively more complete versions of the software working outwards. The SE collects and documents
https://www.mitre.org/publications/systems-engineering-guide/se-lifecycle-building-blocks/requirements-engineering/eliciting-collecting-and-developin… 7/ the part of all team members, and incremental development. The SE 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. For example, a project built on the waterfall model may use the agile model for all or part of the software development phase, or milestones associated with the waterfall model are incorporated into the spiral model. Regardless of the particular model, all approaches should include requirements elicitation and some form of documentation. The activities in the Best Practices and Lessons Learned (below) are often associated with the waterfall model, but many can be modified for use with other models as well. SEs 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 SEs 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
https://www.mitre.org/publications/systems-engineering-guide/se-lifecycle-building-blocks/requirements-engineering/eliciting-collecting-and-developin… 8/ existing systems that are being updated or replaced. Requirements that evolve over time due to mission changes, business environment changes, etc. must be updated to stay current. Challenges exist today with the requirements engineering process. Frequently, sufficient time is not allocated to understand operational concepts and requirements associated with them; requirements are specified but not managed to accommodate changes; requirements are not revisited often enough to further assess trade-offs that users might consider in order to manage schedule and costs. Best Practices and Lessons Learned Apply good interpersonal skills. Such skills are always an asset, but they are a necessity when eliciting requirements. When SEs 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. SEs 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 cost-effective solutions (e.g., process changes).
https://www.mitre.org/publications/systems-engineering-guide/se-lifecycle-building-blocks/requirements-engineering/eliciting-collecting-and-developi… 10/ 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 SE answer the question: What is the real need that the project and its product are intended to address? The SE 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 SE's ability to state the problem in an implementation-independent manner is extremely
https://www.mitre.org/publications/systems-engineering-guide/se-lifecycle-building-blocks/requirements-engineering/eliciting-collecting-and-developi… 11/ 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 the capability scope. The SE generates the 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 under way. Stakeholders review it and customers approve it. The SE'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 following topics. Some top-level
https://www.mitre.org/publications/systems-engineering-guide/se-lifecycle-building-blocks/requirements-engineering/eliciting-collecting-and-developi… 13/ 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 SE 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 SE elicits requirements directly or indirectly based on users' informal narratives, observing the user environment, or capturing their responses to targeted questions. The SE 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
https://www.mitre.org/publications/systems-engineering-guide/se-lifecycle-building-blocks/requirements-engineering/eliciting-collecting-and-developi… 14/ 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 "describe your ideal system" may open up areas not previously considered. The SE 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 SE consults with SMEs to ensure that system, security, and operational requirements are complete and feasible; the SE also brings attention to and incorporates into the requirements any government and other regulations that must be taken into account during the program. Project size and type, complexity, schedule, number of interviewees, and locations will determine the 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 SEs analyze related documents, system interfaces, and data, they are likely to discover new requirements. Reverse engineering may be
https://www.mitre.org/publications/systems-engineering-guide/se-lifecycle-building-blocks/requirements-engineering/eliciting-collecting-and-developi… 16/ 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 SE can assess the requirements (see the SEG article Special Considerations for Issues of Uncertainty: Prototyping and Experimentation). Visual aids that focus 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. SEs update
https://www.mitre.org/publications/systems-engineering-guide/se-lifecycle-building-blocks/requirements-engineering/eliciting-collecting-and-developi… 17/ requirements when changes are made at reviews and meetings, and they track issues (e.g., action items) and conflicts. When conflicts cannot be resolved, SEs bring 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 SE 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, they 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 who contributed
https://www.mitre.org/publications/systems-engineering-guide/se-lifecycle-building-blocks/requirements-engineering/eliciting-collecting-and-developi… 19/ the SE, 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, SEs, designers, developers, integrators, and testers should be formed and maintained. Capture lessons learned. When a project ends, project members, including managers, are encouraged to document their experiences, good and bad. A facilitator conducts a lessons learned review with project participants to identify best practices and processes that need improvement. Summary 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 under way 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 SEG articles include Analyzing and Defining Requirements, Agile Acquisition Strategy, and
https://www.mitre.org/publications/systems-engineering-guide/se-lifecycle-building-blocks/requirements-engineering/eliciting-collecting-and-developi… 20/ Stakeholder Assessment and Management. References and Resources
- Manifesto for Agile Software Development , accessed April 28, 2015. Additional References and Resources Ambler, S. W., September 1, 2005, "Seeking Stakeholders," Doctor Dobb's Digest. Ambler, S. W., October 1, 2005, "Requirements Wisdom," Doctor Dobb's Digest. Ambler, S. W., September 16, 2008, “Beyond Functional Requirements on Agile Projects" Doctor Dobb's Digest. Bahill, T., "What Is Systems Engineering? A Consensus of Senior Systems Engineers," accessed April 28, 2015. Florence, A., April 2002, "Reducing Risks Through Proper Specification of Software Requirements," CrossTalk: The Journal of Defense Software Engineering. Florence, A., October 2003, "Requirements Validation and Verification," QAI Journal. Florence, A., and W. Bail, October 2008, "Effective Requirements Practices," presented to the 11th Annual NDIA Systems Engineering Conference, San Diego.
