User:BenteLaraM/Requirements analysis
| Part of a series on |
| Software development |
|---|
In systems engineering and software engineering, requirements analysis concerns the analysis of elicited requirements to understand and document them. [2] 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.[3]
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.[4]
Requirements analysis is critical to the success or failure of a systems or software project.[5] 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[edit]
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. [6][7]
- 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. [7][8]
- 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.[7][8] It might become clear that some requirements need clarification. In this case, analysts can go back and do more elicitation.[9]
- Refining requirements. Requirement analysis involves refining the requirements to ensure that all stakeholders understand them and scrutinizing them for errors, omissions and other deficiencies.[9] 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.
Requirements analysis techniques[edit]
Stakeholder identification[edit]
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.[2] The stakeholders of a system are the main source of requirements [8]. Therefore, analyzing requirements goes hand in hand with performing a stakeholder analysis. Typical stakeholder roles include: [10]
- End-users
- Sponsors
- Managers
- Developers
- Authorities
- Customers
Joint Requirements Development (JRD) Sessions[edit]
Requirements often have cross-functional implications that are unknown to individual stakeholders and often missed or incompletely defined during stakeholder interviews.[11] 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[edit]
Joint application development is a systems development method that encompasses approaches for enhancing user participation, improving the quality of specifications, and expediting development.[12] 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. [13] 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.[7]
Requirements analysis work products[edit]
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[edit]
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[14], 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. [15]
- The requirement list is non-representational, which makes difficult to identify which requirement is most important and by what procedure the requirements suit together. [16] 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.[16] 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[edit]
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. [8] 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[8], 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.[8]
Use cases[edit]
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. [2] Use cases are often written using form templates in natural language or are modeled by using UML activity diagrams.[8] 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[edit]
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.[17] The advantages of using stories are that they are simple, comprehensible and that they are popular in agile development.[18] 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.[19] There are multiple templates to use when writing user stories an example can be the following structure when documenting user stories[20]: As a [role], I want to [goal], so that [benefit].
Requirements analysis issues[edit]
Stakeholder issues[edit]
Steve McConnell, in his book "Rapid Development"[21], 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[edit]
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.
See also[edit]
- Business analysis
- Business Analysis Body of Knowledge (BABOK)
- Business process reengineering
- Creative brief
- Data modeling
- Design brief
- Functional requirements
- Information technology
- Model-driven engineering
- Model Transformation Language
- Needs assessment
- Non-functional requirements
- Process architecture
- Process modeling
- Product fit analysis
- Requirements elicitation
- Requirements Engineering Specialist Group
- Requirements management
- Requirements Traceability
- Search Based Software Engineering
- Software prototyping
- Software requirements
- Software Requirements Specification
- Systems analysis
- System requirements
- System requirements specification
- User-centered design
References[edit]
- ^ Systems Engineering Fundamentals Archived 2011-07-22 at the Wayback Machine Defense Acquisition University Press, 2001
- ^ a b c Glinz, Martin. "A glossary of requirements engineering terminology." Standard Glossary of the Certified Professional for Requirements Engineering (CPRE) Studies and Exam, Version 1 (2011): 56
- ^ Kotonya, Gerald; Sommerville, Ian (1998). Requirements Engineering: Processes and Techniques. Chichester, UK: John Wiley and Sons. ISBN 9780471972082.
- ^ Mylopoulos, John, et al. "Exploring alternatives during requirements analysis." IEEE Software 18.1 (2001): 92-96.
- ^ Alain Abran; James W. Moore; Pierre Bourque; Robert Dupuis, eds. (March 2005). "Chapter 2: Software Requirements". Guide to the software engineering body of knowledge (2004 ed.). Los Alamitos, CA: IEEE Computer Society Press. ISBN 0-7695-2330-7. Retrieved 2007-02-08.
It is widely acknowledged within the software industry that software engineering projects are critically vulnerable when these activities are performed poorly.
- ^ https://www.gasq.org/files/content/gasq/downloads/certification/REQB/REQB_Agile_Practitioner_Syllabus(1).pdf
- ^ a b c d Paetsch, Frauke, Armin Eberlein, and Frank Maurer. "Requirements engineering and agile software development." WET ICE 2003. Proceedings. Twelfth IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises, 2003.. IEEE, 2003.
- ^ a b c d e f g https://www.ireb.org/content/downloads/2-cpre-foundation-level-syllabus-3-0/cpre_foundationlevel_syllabus_en_v.3.1.pdf
- ^ a b Wiegers, Karl, and Joy Beatty. Software requirements. Pearson Education, 2013.
- ^ Bittner, Kurt, and Ian Spence. Use case modeling. Addison-Wesley Professional, 2003.
- ^ Mishra, Deepti, Alok Mishra, and Ali Yazici. "Successful requirement elicitation by combining requirement engineering techniques." 2008 First International Conference on the Applications of Digital Information and Web Technologies (ICADIWT). IEEE, 2008.
- ^ Davidson, Elizabeth J. "Joint application design (JAD) in practice." Journal of Systems and Software 45.3 (1999): 215-223.
- ^ Macaulay, Linda A. Requirements engineering. Springer Science & Business Media, 2012.
- ^ Huzooree, G., Ramdoo, V.D.: A systematic study on requirement engineering processes and practices in mauritius. Int. J. Adv. Res. Comput. Sci. Softw. Eng. 5(2). 40–45 (2015). ISSN 2277 128X
- ^ Pressman, R.S.: Software engineering: a practitioner’s approach. Software Engineering. pp. 243–250 (2010). ISBN 978–0–07–337597–7
- ^ a b Reffat, R.: Utilization of artificial intelligence concepts and techniques for enriching the quality of architectural design artifacts. In: Proceedings of the 1st International Conference in Information Systems. 5(1), 1–13 (2002)
- ^ Cohn, Mike. "Advantages of user stories for requirements." InformIT Network, available at: http://www. informit. com/articles (2004).
- ^ Lucassen, G., Dalpiaz, F., van der Werf, J.M., Brinkkemper, S.: The use and effectiveness of user stories in practice. In: Proceedings of the International Working Conference on Requirements Engineering: Foundation for Software Quality (REFSQ) (2016)
- ^ Lucassen, Garm, et al. "The use and effectiveness of user stories in practice." Requirements Engineering: Foundation for Software Quality: 22nd International Working Conference, REFSQ 2016, Gothenburg, Sweden, March 14-17, 2016, Proceedings 22. Springer International Publishing, 2016.
- ^ Cohn, M.: User Stories Applied: For Agile Software Development. Addison-Wesley, Redwood City (2004)
- ^ McConnell, Steve. Rapid Development: Rapid Devment _p1. Microsoft Press, 1996.
Bibliography[edit]
- Brian Berenbach; Daniel Paulish; Juergen Katzmeier; Arnold Rudorfer (2009). Software & Systems Requirements Engineering: In Practice. New York: McGraw-Hill Professional. ISBN 978-0-07-160547-2.
- Hay, David C. (2003). Requirements Analysis: From Business Views to Architecture (1st ed.). Upper Saddle River, NJ: Prentice Hall. ISBN 0-13-028228-6.
- Laplante, Phil (2009). Requirements Engineering for Software and Systems (1st ed.). Redmond, WA: CRC Press. ISBN 978-1-4200-6467-4.
- McConnell, Steve (1996). Rapid Development: Taming Wild Software Schedules (1st ed.). Redmond, WA: Microsoft Press. ISBN 1-55615-900-5.
- Nuseibeh, B.; Easterbrook, S. (2000). Requirements engineering: a roadmap (PDF). ICSE'00. Proceedings of the conference on the future of Software engineering. pp. 35–46. CiteSeerX 10.1.1.131.3116. doi:10.1145/336512.336523. ISBN 1-58113-253-0.
- Andrew Stellman & Jennifer Greene (2005). Applied Software Project Management. Cambridge, MA: O'Reilly Media. ISBN 0-596-00948-8.
- Karl Wiegers & Joy Beatty (2013). Software Requirements (3rd ed.). Redmond, WA: Microsoft Press. ISBN 978-0-7356-7966-5.
External links[edit]
- Peer-reviewed Encyclopedia Entry on Requirements Engineering and Analysis
- Defense Acquisition University Stakeholder Requirements Definition Process[dead link]---Stakeholder Requirements Definition Process at the Wayback Machine (archived December 23, 2015)
- MIL-HDBK 520 Systems Requirements Document Guidance
