- Requirements analysis
Requirements analysis in
systems engineering andsoftware engineering , encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product, taking account of the possibly conflictingrequirements of the various stakeholders, such as beneficiaries or users. Systematic requirements analysis is also known as "requirements engineering". [cite book
first = Karl E.
last = Wiegers
authorlink =
year = 2003
title = Software Requirements 2: Practical techniques for gathering and managing requirements throughout the product development cycle
edition = 2nd ed.
publisher = Microsoft Press
location = Redmond
id = ISBN 0-7356-1879-8
url = http://www.processimpact.com] It is sometimes referred to loosely by names such as "requirements gathering", "requirements capture", or "requirements specification". The term "requirements analysis" can also be applied specifically to the analysis proper (as opposed to elicitation or documentation of the requirements, for instance).Requirements analysis is critical to the success of a development project. [cite book
editor = Executive editors: Alain Abran, James W. Moore; editors Pierre Bourque, Robert Dupuis
title = Guide to the software engineering body of knowledge|url = http://www.swebok.org
accessdate = 2007-02-08|edition=2004 Version| year = 2005 | month = March
publisher = IEEE Computer Society Press | location = Los Alamitos, CA | isbn = 0-7695-2330-7
chapter = Chapter 2: Software Requirements | chapterurl = http://www.swebok.org/ch2.html
quote = It is widely acknowledged within the software industry that software engineering projects are critically vulnerable when these activities are performed poorly.] Requirements must be actionable, measurable, testable, 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 activity:
*Eliciting requirements: the task of communicating with customers and users to determine what their requirements are. This is sometimes also called requirements gathering.
*Analyzing requirements: determining whether the stated requirements are unclear, incomplete, ambiguous, or contradictory, and then resolving these issues.
*Recording requirements: Requirements may be documented in various forms, such as natural-language documents,use case s, user stories, or process specifications.Requirements analysis can be a long and arduous 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. Historically, this has included such things as holding
interview s, or holdingfocus group s (more aptly named in this context as requirements workshops - see below) and creating requirements lists. More modern techniques include prototyping, and use cases. 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 analysis topics
Stakeholder identification
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:
*those organizations that integrate (or should integrate) horizontally with the organization the analyst is designing the system for
*any back office systems or organizations
*Senior management.Stakeholder interviews
Stakeholder interviews are a common method used in requirement analysis.These interviews may reveal requirements not previously envisaged as being within the scope of the project, and requirements may be contradictory. However, each stakeholder will have an idea of their expectation or will have visualized their 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 to hundreds of pages.
Measurable goals
Best practices take the composed list of requirements merely as clues and repeatedly ask "why?" until the actual business purposes are discovered. Stakeholders and developers can then devise tests to measure what level of each goal has been achieved thus far. Such goals change more slowly than the long list of specific but unmeasured requirements. Once a small set of critical, measured goals has been established, rapid prototyping and short iterative development phases may proceed to deliver actual stakeholder value long before the project is half over.
Prototypes
In the mid-1980s,
prototyping was seen as the solution to the requirements analysis problem. Prototypes are mock-ups of an application. Mock-ups allow users to visualize an application that hasn't yet been constructed. Prototypes help users get an idea of what the system will look like, and make it easier for users to make design decisions without waiting for the system to be built. Major improvements in communication between users and developers were often seen with the introduction of prototypes. Early views of applications led to fewer changes later and hence reduced overall costs considerably.However, over the next decade, while proving a useful technique, prototyping did not solve the requirements problem:
* Managers, once they see a prototype, may have a hard time understanding that the finished design will not be produced for some time.
* Designers often feel compelled to use patched together prototype code in the real system, because they are afraid to 'waste time' starting again.
* Prototypes principally help with design decisions and user interface design. However, they can not tell you what the requirements originally were.
* Designers and end users can focus too much on user interface design and too little on producing a system that serves the business process.
* Prototypes work well for user interfaces, screen layout and screen flow but are not so useful for batch or asynchronous processes which may involve complex database updates and/or calculations.Prototypes can be flat diagrams (referred to as 'wireframes') or working applications using synthesized functionality. Wireframes are made in a variety of graphic design documents, and often remove all color from the software design (i.e. use a greyscale color palette) in instances where the final software is expected to have
graphic design applied to it. This helps to prevent confusion over the final visual look and feel of the application.Use cases
A use case is a technique for documenting the potential requirements of a new system or software change. Each use case provides one or more "scenarios" that convey how the system should interact with the end user or another system to achieve a specific business goal. Use cases typically avoid technical jargon, preferring instead the language of the
end user or "domain expert ". Use cases are often co-authored by requirements engineers and stakeholders.Use cases are deceptively simple tools for describing the behavior of software or systems. A use case contains a textual description of all of the ways which the intended users could work with the software or system. Use cases do not describe any internal workings of the system, nor do they explain how that system will be implemented. They simply show the steps that a user follows to perform a task. All the ways that users interact with a system can be described in this manner.
oftware requirements specification
A
software requirements specification (SRS) is a complete description of the behavior of the system to be developed. It includes a set of use cases that describe all of the interactions that the users will have with the software. Use cases are also known as functional requirements. In addition to use cases, the SRS also contains nonfunctional (or supplementary) requirements.Non-functional requirements are requirements which impose constraints on the design or implementation (such as performance requirements, quality standards, or design constraints).Recommended approaches for the specification of software requirements are described by IEEE 830-1998. This standard describes possible structures, desirable contents, and qualities of a software requirements specification.
Requirements analysis issues
;Stakeholder issuesSteve McConnell, in his book "Rapid Development", details a number of ways users can inhibit requirements gathering:
* Users do not understand what they want or users don't have a clear idea of their requirements
* Users will not commit to a set of written requirements
* Users insist on new requirements after the cost and schedule have been fixed
* Communication with users is slow
* Users often do not participate in reviews or are incapable of doing so
* Users are technically unsophisticated
* Users do not understand the development process
* Users do not know about present technologyThis may lead to the situation where user requirements keep changing even when system or product development has been started.;Engineer/developer issuesPossible problems caused by engineers and developers during requirements analysis are:
* Technical personnel and end users may have different vocabularies. Consequently, they may wrongly believe they are in perfect agreement until the finished product is supplied.
* Engineers and developers may try to make the requirements fit an existing system or model, rather than develop a system specific to the needs of the client.
* Analysis may often be carried out by engineers or programmers, rather than personnel with the people skills and the domain knowledge to understand a client's needs properly.;Attempted solutionsOne attempted solution to communications problems has been to employ specialists in business or system analysis.
Techniques introduced in the 1990s like
Prototyping ,Unified Modeling Language (UML),Use case s, andAgile software development are also intended as solutions to problems encountered with previous methods.Also, a new class of application simulation or application definition tools have entered the market. These tools are designed to bridge the communication gap between business users and the IT organization — and also to allow applications to be 'test marketed' before any code is produced. The best of these tools offer:
* electronic whiteboards to sketch application flows and test alternatives
* ability to capture business logic and data needs
* ability to generate high fidelity prototypes that closely imitate the final application
* interactivity
* capability to add contextual requirements and other comments
* ability for remote and distributed users to run and interact with the simulationee also
*
Business analysis
*Business process reengineering
*Creative brief
*Design brief
*Information technology
*Data modeling
*Functional requirements
*Model-driven engineering
*Model Transformation Language
*Non-functional requirements
*Process architecture
*Process modeling
*Requirements elicitation
*Requirements management
*Requirements Traceability
*Search Based Software Engineering
*Software prototyping
*Software Requirements Specification
*Systems analysis
*System requirements
*Service-Oriented Modeling References
Further reading
*cite book | first = Steve | last = McConnell | authorlink = | year = 1996 | title = Rapid Development: Taming Wild Software Schedules | edition = 1st ed. | publisher = Microsoft Press | location = Redmond, WA | id = ISBN 1-55615-900-5 | url = http://www.stevemcconnell.com/
*cite book | first = Karl E. | last = Wiegers | authorlink = | year = 2003 | title = Software Requirements 2: Practical techniques for gathering and managing requirements throughout the product development cycle | edition = 2nd ed. | publisher = Microsoft Press | location = Redmond | id = ISBN 0-7356-1879-8 | url = http://www.processimpact.com
*cite book | author = Andrew Stellman and Jennifer Greene | authorlink = | year = 2005 | title = Applied Software Project Management | edition = | publisher = O'Reilly Media | location = Cambridge, MA | id = ISBN 0-596-00948-8 | url = http://www.stellman-greene.comExternal links
* [http://www.processimpact.com/goodies.shtml#reqs Requirements Engineering Process "Goodies"]
* [http://www.cs.toronto.edu/~sme/papers/2000/ICSE2000.pdf Requirements Engineering: A Roadmap] (PDF) article by Bashar Nuseibeh and Steve Easterbrook, 2000.
* [http://softwaresurvival.blogspot.com/2007/03/undreamt-requirements.html Undreamt Requirements Analysis]
* [http://infogenium.typepad.com/inside_infogenium/2007/07/getting-started.html Getting Started With Use Cases]
Wikimedia Foundation. 2010.
