User:BenteLaraM/Requirements analysis



In systems engineering and software engineering, requirements analysis concerns the analysis of elicited requirements to understand and document them. Requirements analysis is part of requirements management and the requirements engineering process and focuses on the tasks that determine requirements to meet the new or altered product or project, taking into account the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating and managing system or software requirements.

Requirements analysis is the logical breakdown that proceeds from elicitation. The analysis involves reaching a richer and more precise understanding of each requirement and representing sets of requirements in multiple, complementary ways. In addition, requirements analysis often involves exploring and evaluating alternatives to the elicited requirements.

Requirements analysis is critical to the success or failure of a systems or software project. The requirements should be documented in a way that is actionable, measurable, testable, traceable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design. Requirements analysis is performed by business analysts to analyze and assess the quality of the requirements of a business its system, process, or product.

For information on requirements analysis as a synonym for requirements engineering, see requirements engineering.

Overview
Conceptually, requirements analysis can include the following activities:


 * Requirement prioritization. Requirement prioritization is the process of ranking or grading requirements in ascending order of relative importance and urgency for upcoming implementation releases. Through requirement prioritization, conflicts in requirements are resolved with the support stakeholders.
 * Recording requirements: Requirements may be documented or recorded in various forms, usually including a summary list and may include natural-language-based documents, use cases, user stories, process specifications and a variety of models including data models.  
 * Evaluation of requirements. Determining the quality of the stated requirements by checking whether the requirements are adequate, necessary, unambiguous, complete (self-contained), understandable, verifiable, consistent, and resolving any apparent conflicts. It might become clear that some requirements need clarification. In this case, analysts can go back and do more elicitation.
 * Refining requirements. Requirement analysis involves refining the requirements to ensure that all stakeholders understand them and scrutinizing them for errors, omissions and other deficiencies. Requirements quality can be improved through the use of various methods such as visualization, consistent use of templates, and documenting dependencies and interrelationships among requirements, as well as any assumptions and congregations.

The analysis of requirements happens on multiple occasions during the requirements engineering process, such as after requirements elicitation and also before and after requirements specification. This is because requirements are not stable, but continue to evolve during a project's lifecycle. When requirements have been elicited, requirement analysis is performed to uncover the prioritization of requirements. After the requirements have been specified, requirements analysis is performed once again to evaluate and refine the specification of the set requirements.

Stakeholder identification
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 or confirm all the stakeholders, in order to ensure their needs are taken into account. In requirements engineering, a stakeholder is a person or organization that either has a direct or indirect influence on a system's requirements or is in some way impacted by the system. The stakeholders of a system are the main source of requirements. Therefore, analyzing requirements goes hand in hand with performing a stakeholder analysis. Typical stakeholder roles include:


 * End-users
 * Sponsors
 * Managers
 * Developers
 * Authorities
 * Customers

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 business analyst, wherein stakeholders participate in discussions to elicit requirements, analyze their details and uncover cross-functional implications. 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.

Joint Application Development (JAD) Sessions
Joint application development is a systems development method that encompasses approaches for enhancing user participation, improving the quality of specifications, and expediting development. This method consists of group sessions with a structured analysis approach. During Joint Application Development sessions, stakeholders including executives, project managers, users, system experts, and external technical personnel engage in discussions aimed at defining and designing a project with a high level of detail. The session leader plays a crucial role in ensuring that the discussion remains on course and that the goals of the JAD session, which include defining the project, designing a solution, and monitoring progress until completion, are met. JAD sessions promote collaboration and understanding among stakeholders, as participants with diverse backgrounds come together to gather the information that forms the foundation for further requirements elicitation.

Requirements analysis work products
Analysts can employ several techniques to document requirements. These may include the development user stories, the identification of use cases, prototyping and the creation of requirements lists. Using consistent templates or visualization allows for a clear and consistent presentation of the requirements, making it easier for stakeholders to understand and review them. Additionally, documenting dependencies and interrelationships among requirements, as well as any assumptions and congregations, can help to identify potential issues and ensure that the final system is fully functional and meets the needs of all stakeholders.

Contract-style requirement lists
Contract-style requirement lists are a traditional method of documenting requirements which provides a specification of requirements and agreement between the stakeholders. It also provides a high-level description of the large system, which can lead to lists of up to hundreds of pages in length for complex systems. The strengths of this method include providing a checklist of requirements and serving as a contract between project sponsors and developers. Additionally, for large systems, it can provide a high-level description from which lower-level requirements can be derived.

Major issues identified by various researchers regarding usage of this technique are given as follows:


 * Contract-style requirement lists create an unreliable logic of contract between the stakeholders and developers.
 * The requirement list is non-representational, which makes difficult to identify which requirement is most important and by what procedure the requirements suit together. This makes it hard to understand if requirements fit or work together, and makes for a lack of reflection of relationships and dependencies between requirements.
 * Many people who read contract-style requirements lists propose diverse visions and interpretations of the system. This can cause the lack of readability, through the abstraction of requirements with little context.
 * Additionally, these lists do not replace the need for careful review of requirements with stakeholders in order to gain a better-shared understanding of the implications for the design of the desired system/application.

Prototypes
In requirements engineering, prototypes are a means of specifying requirements by example and of validating requirements. Prototypes are used if the involved stakeholders do not want to write and review natural-language based, template-based or model-based work products. A popular form of prototype is a mock-up, which is a medium-fidelity prototype. Mock-ups help future users and other stakeholders to get an idea of what the system will look like. Prototyping can be a powerful tool in requirements analysis, as it allows aspects of the application to be demonstrated and shared to stakeholders before the application is built. This can help to confirm that there is a clear understanding of the stakeholders' needs and requirements and to ensure that the final system meets the business needs. Prototypes can be used to create a shared understanding between users and developers, clarify requirements, or validate requirements at different levels of fidelity.

Use cases
A use case is a structure for documenting the functional requirements of a system. A use case is a description of a sequence of interactions (i.e. scenarios) between a user and a system that, when executed, provides added value or achieves a certain business goal. Use cases are used in order to describe and specify requirements from a user’s perspective. Use cases are often written using form templates in natural language or are modeled by using UML activity diagrams. Use cases should not describe the internal workings of the system, nor should they explain how that system will be implemented. Instead, they show the steps needed to perform a task without sequential assumptions.

User Stories
As an alternative to requirement lists, Agile Software Development uses user stories to describe requirements in everyday language. This approach is considered to be more reader-friendly and better able to capture the context and relationships between requirements. User stories exhibit  some of the same characteristics of use cases or traditional requirements statements. The advantages of using stories are that they are simple, comprehensible and that they are popular in agile development. They are easy to learn and can be also applied by stakeholders without any notation or modeling skills. Furthermore, user stories stimulate collaboration and facilitate planning, estimation, and prioritization. There are multiple templates to use when writing user stories an example can be the following structure when documenting user stories : As a [role], I want to [goal], so that [benefit].

Stakeholder issues
Steve McConnell, in his book "Rapid Development", highlights several ways in which users can inhibit the process of gathering requirements. These include users not understanding what they want or not having a clear idea of their requirements, users being unwilling to commit to a set of written requirements, users insisting on new requirements after the cost and schedule have been fixed, slow communication with users, users not participating in reviews or being incapable of doing so, users being technically unsophisticated, users not understanding the development process, and users not having knowledge of current technology. These issues can lead to a situation where user requirements keep changing even after system or product development has begun, making it difficult to deliver a final product that meets the needs of all stakeholders.

Engineer/developer issues
There are several potential problems that can be caused by engineers and developers during the requirements analysis phase of a project. One issue is that engineers and developers may have a natural inclination to begin writing code before the requirements analysis is complete, which can lead to changes in the code once the actual requirements are known. This can add extra time and cost to the project.

Another problem is that technical personnel and end-users may have different vocabularies, which can lead to misunderstandings and false assumptions about the agreement until the finished product is delivered. Engineers and developers may also try to fit the requirements into an existing system or model, rather than developing a system that is specific to the needs of the client, which can lead to a less optimal solution.