Requirements analysis

In systems engineering and software engineering, requirements analysis focuses on the tasks that determine the needs or conditions to meet the new or altered product or project, taking account of the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating, and managing software or system requirements. Requirements analysis is critical to the success or failure of systems or software projects. The requirements should be documented, actionable, measurable, testable, traceable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design.

Overview Conceptually, requirements analysis includes three types of activities:

Eliciting requirements: (e.g. the project charter or definition), business process documentation, and stakeholder interviews. This is sometimes also called requirements gathering or requirements discovery. Recording requirements: Requirements may be documented in various forms, usually including a summary list, and may include natural-language documents, use cases, user stories, process specifications, and a variety of models including data models. Analyzing requirements: determining whether the stated requirements are clear, complete, unduplicated, concise, valid, consistent and unambiguous, and resolving any apparent conflicts. Analyzing can also include sizing requirements. Requirements analysis can be a long and tiring process during which many delicate psychological skills are involved. New systems change the environment and relationships between people, so it is important to identify all the stakeholders, take into account all their needs, and ensure they understand the implications of the new systems. Analysts can employ several techniques to elicit the requirements from the customer. These may include the development of scenarios (represented as user stories in agile methods), the identification of use cases, the use of workplace observation or ethnography, holding interviews, or focus groups (more aptly named in this context as requirements workshops, or requirements review sessions) and creating requirements lists. Prototyping may be used to develop an example system that can be demonstrated to stakeholders. Where necessary, the analyst will employ a combination of these methods to establish the exact requirements of the stakeholders, so that a system that meets the business needs is produced. Requirements quality can be improved through these and other methods:

Visualization. Using tools that promote better understanding of the desired end-product such as visualization and simulation. Consistent use of templates. Producing a consistent set of models and templates to document the requirements. Documenting dependencies. Documenting dependencies and interrelationships among requirements, as well as any assumptions and congregations.

Requirements analysis topics

Stakeholder identification See Stakeholder analysis for a discussion of people or organizations (legal entities such as companies, and standards bodies) that have a valid interest in the system. They may be affected by it either directly or indirectly. A major new emphasis in the 1990s was a focus on the identification of stakeholders. It is increasingly recognized that stakeholders are not limited to the organization employing the analyst. Other stakeholders will include:

anyone who operates the system (normal and maintenance operators) anyone who benefits from the system (functional, political, financial, and social beneficiaries) anyone involved in purchasing or procuring the system. In a mass-market product organization, product management, marketing, and sometimes sales act as surrogate consumers (mass-market customers) to guide the development of the product. organizations that regulate aspects of the system (financial, safety, and other regulators) people or organizations opposed to the system (negative stakeholders; see also Misuse case) organizations responsible for systems that interface with the system under design. those organizations that integrate horizontally with the organization for whom the analyst is designing the system.

Joint Requirements Development (JRD) Sessions Requirements often have cross-functional implications that are unknown to individual stakeholders and often missed or incompletely defined during stakeholder interviews. These cross-functional implications can be elicited by conducting JRD sessions in a controlled environment, facilitated by a trained facilitator (Business Analyst), wherein stakeholders participate in discussions to elicit requirements, analyze their details, and uncover cross-functional implications. A dedicated scribe should be present to document the discussion, freeing up the Business Analyst to lead the discussion in a direction that generates appropriate requirements that meet the session objective. JRD Sessions are analogous to Joint Application Design Sessions. In the former, the sessions elicit requirements that guide design, whereas the latter elicit the specific design features to be implemented in satisfaction of elicited requirements.

Contract-style requirement lists One traditional way of documenting requirements has been contract-style requirement lists. In a complex system such requirements lists can run hundreds of pages long. An appropriate metaphor would be an extremely long shopping list. Such lists are very much out of favor in modern analysis; as they have proved spectacularly unsuccessful at achieving their aims; but they are still seen to this day.

Strengths Provides a checklist of requirements. Provide a contract between the project sponsor(s) and developers. For a large system can provide a high level description from which lower-level requirements can be derived.

… excerpt ends here. Continue reading the full article.