Requirements analysis
From Free net encyclopedia
Requirements analysis, in systems engineering and software engineering, encompasses all of the tasks that go into the instigation, scoping and definition of a new or altered system. Requirements analysis is an important part of the system design process; whereby requirements engineers, business analysts, along with systems engineers or software developers, identify the needs or requirements of a client; having identified these requirements they are then in a position to design a solution.
Requirements analysis is also known under other names:
- requirements engineering
- requirements gathering
- requirements capture
- operational concept documenting
- systems analysis
- requirements specification
During most of the history of software engineering requirements analysis has been considered to be a relatively easy part of the processTemplate:Fact. However, in the last decade or so, it has become increasingly recognised as being the most vital part of the process; given that the failure to properly identify requirements makes it virtually impossible for the finished piece of software to meet the needs of the client or be finished on time.
Contents |
The challenge
Successfully completing a "requirements analysis" task is a challenge. In the first place, it is not easy to identify all the stakeholders, give them all an appropriate form of input, and document all their input in a clear and concise format. And there are constraints. The requirements engineer is expected to determine whether or not the new system is:
In the rush of enthusiasm associated with a new project, there is always a temptation to downplay the importance of requirements analysis. However, studies of previous projects reveal that costs and technical risks can be reduced through rigorous and thorough up-front requirements engineeringTemplate:Fact.
General problem
The general difficulties involved with requirements analysis are increasingly well known:
- the right people with adequate experience, technical expertise, and language skills may not be available to lead the requirements engineering activities;
- the initial ideas about what is needed are often incomplete, wildly optimistic, and firmly entrenched in the minds of the people leading the acquisition process; and
- the difficulty of using the complex tools and diverse methods associated with requirements gathering may negate the hoped for benefits of a complete and detailed approach.
Stakeholder issues
Steve McConnell, in his book Rapid Development, details a number of ways users can inhibit requirements gathering:
- Users don't understand what they want
- Users won't 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 don't understand the software development process.
This commonly leads to the situation where user requirements keep changing even when the software development has been started. Because new requirements may sometimes mean changing the technology as well, the importance of finalising user requirements before the commencement of development should be made very clear to the Business Users. Knowing their objectives and expectations regarding the solution beforehand and documenting agreed requirements is fundamental to the success of a project.
Developer issues
However, developers are often also at blame. Typical problems caused by software developers are:
- Software developers and end users often have different vocabularies. Consequently, they can believe they are in perfect agreement until the finished product is supplied. The duty to bridge that gap is often assigned to Business Analysts, who analyze and document the business processes of business units affected by the proposed business solution, and Business Systems Analysts, who analyze and document the proposed business solution from a systems perspective.
- Software developers often try to make the requirements fit an existing system or model, rather than develop a system specific to the needs of the client.
- Analysis is often carried out by programmers, rather than business analysts. It is often the case that programmers lack the people skills and the domain knowledge to understand a business process properly.
Solutions
One of the solutions to this problem has been recognising that requirements analysis is a specialist field best carried out by experts, i.e. business or system analysts, who could bridge the gap between the business and IT (Information Technology) worlds. While this approach has helped, it has often been difficult to find staff who possess equally good people and technical skills. In addition, the techniques used to analyse requirements have not proven sufficiently effective in all situations. Techniques introduced in the 1990s like Prototyping, Unified Modeling Language (UML), Use cases, and Agile software development are often put forward as a promising solution to this issue.
More recently, however, attempts have been made to address these difficulties with the establishment of the International Institute of Business Analysis, whose main goals are the creation of a common Body of Knowledge for Business Analysis, and to use it as basis for certification of Business Analysis Professionals.
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 simulation
Main Techniques
Requirements analysis can be a long and arduous process. The requirements specialists do their work by talking to people, documenting their findings, analyzing the collected information to discover inconsistencies and oversights, and then talking to people again. This process can go on for anywhere from a week to a year or more, and may continue throughout the life cycle of a system.
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. Frequently, this objective is not met because:
- there is not enough communication up front and important needs are overlooked when the system is implemented; and/or
- there is not enough ongoing communication during system development and the users are disappointed by the new system's characteristics.
To keep all these discussions well organized and efficient, the evolving requirements must be documented.
Analysts can employ several techniques to get the requirements from the customer. Historically, this has included such things as holding interviews, or holding focus groups (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.
Stakeholder interviews
Stakeholder interviews are obviously necessary in requirement specification. However, in any large system a number of individuals need to be interviewed which increases time and cost. This often leads to pressure to shorten the analysis phase despite the impact incomplete requirements can have on a project. Stakeholder interviews also often reveal major shortcomings with regard to how existing business processes work and identify how to improve this in the future. While this is ultimately positive for the business, it will also lead to previously unforseen increases in time and cost. This can be further compounded by the discovery that different users have differing or even contradictory requirements.
Requirement workshops
To overcome these issues, where systems are complex the usual method is to use requirement workshops. The analyst brings the main stakeholders in the system together in order to analyse the system and develop the solution. These workshops are more properly termed Joint Requirements Development (JRD) sessions, where requirements are jointly identified and defined by stakeholders.
Such workshops are ideally carried out in a controlled environment, so that the stakeholders are not distracted. A facilitator can be used to keep the process focused and these sessions will often benefit from a dedicated scribe to document the discussion. Facilitators may make use of a projector and diagramming software or may use props as simple as paper and markers. Often multiple workshops are required to bring the process to a successful conclusion.
Requirements workshops are considered to be a very useful technique which can save significant time. However, it can be hard to get all the required stakeholders together at one time.
A more general weakness is that some stakeholders do not contribute forcefully enough in workshops and their requirements will not receive the appropriate attention, inevitably producing a limited solution. Additionally, while requirement workshops are an excellent technique for modelling the existing system, they are not so useful for defining the nature of the solution.
Contract-style requirement lists
One way of documenting requirements has been contract style requirement lists. In a complex system such requirements lists can run to hundreds of pages. An appropriate metaphor would be an extremely long shopping list. Such lists are very much out of favour 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.
Weaknesses:
- Such lists can run to hundreds of pages. It is virtually impossible to read such documents as a whole and have a coherent understanding of the system.
- Such requirements lists abstract all the requirements and so there is little context
- This abstraction makes it impossible to see how the requirements fit together.
- This abstraction makes it difficult to identify which are the most important requirements.
- This abstraction means that the more people who read such requirements the more different visions of the system you get.
- This abstraction means that it's extremely difficult to be sure that you have the majority of the requirements. Necessarily, these documents speak in generality; but the devil, as they say, is in the details.
- These lists create a false sense of mutual understanding between the stakeholders and developers.
- These contract style lists give the stakeholders a false sense of security that the developers must achieve certain things. However, due to the nature of these lists, they inevitably miss out crucial requirements which are identified later in the process. Developers use these discovered requirements to renegotiate the terms and conditions in their favour.
- These requirements lists are no help in system design, since they do not lend themselves to application.
Prototypes
Main article: Prototyping
In the mid-1980s, prototyping became seen as the solution to the requirements analysis problem. Prototypes are mock ups of the screens of an application which allow users to visualize the application that isn't yet 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. When they were first introduced the initial results were considered amazing. Major improvements in communication between users and developers were often seen with the introduction of prototypes. Early views of the screens led to fewer changes later and hence reduced overall costs considerably.
However, over the next decade, while proving a useful technique, it did not solve the requirements problem:
- Managers once they see the prototype have a hard time understanding that the finished design will not be produced for some time.
- Designers often feel compelled to use the 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't tell you what the requirements were originally.
- 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 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 colour from the software design (i.e. use a greyscale colour 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
Main article: Use case
A use case is a technique for capturing 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 software developers and end users.
Use cases are deceptively simple tools for describing the behavior of the software. A use case contains a textual description of all of the ways that the intended users could work with the software through its interface. Use cases do not describe any internal workings of the software, nor do they explain how that software will be implemented. They simply show the steps that the user follows to use the software to do his work. All of the ways that the users interact with the software can be described in this manner.
During the 1990s use cases have rapidly become the most common practice for capturing functional requirements. This is especially the case within the object-oriented community where they originated, but their applicability is not restricted to object-oriented systems, because use cases are not object oriented in nature.
Each use case focuses on describing how to achieve a single business goal or task. From a traditional software engineering perspective a use case describes just one feature of the system. For most software projects this means that multiple, perhaps dozens, of use cases are needed to fully specify the new system. The degree of formality of a particular software project and the stage of the project will influence the level of detail required in each use case.
A use case defines the interactions between external actors and the system under consideration to accomplish a business goal. Actors are parties outside the system that interact with the system; an actor can be a class of users, roles users can play, or other systems.
Use cases treat the system as a "black box", and the interactions with system, including system responses, are as perceived from outside the system. This is deliberate policy, because it simplifies the description of requirements, and avoids the trap of making assumptions about how this functionality will be accomplished.
A use case should:
- describe a business task to serve a business goal
- be at the appropriate level of detail
- be short enough to implement by one software developer in single release.
Use cases can be very good for establishing the functional requirements; however they are not suited to capturing Non-Functional Requirements.
Software 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. In addition to use cases, the SRS contains functional requirements and nonfunctional requirements. Functional requirements define the internal workings of the software: that is, the calculations, technical details, data manipulation and processing, and other specific functionality that shows how the use cases are to be satisfied. Nonfunctional requirements impose constraints on the design or implementation (such as performance requirements, quality standards, or design constraints).
Stakeholder identification
A major new emphasis in the 1990s was a focus on the identification of stakeholders. This first step is now seen as critical. In the early days systems were built for the projects sponsor(s), who were usually management types. Many systems have been designed by managers with little or no contributions from the eventual users; these systems have tended to fail horrendously. So within the field of software engineering, in the 1970s and 1980s, the understanding of the term stakeholder widened to first the main users of the system, and then peripheral users. However, in the 1990s the search for stakeholders is taking on a more whole system approach. It is increasingly recognised that stakeholders do not just exist in the organisation the analyst is hired by. Other stakeholders will include:
- those organisations that integrate (or should integrate) horizontally with the organisation the analyst is designing the system for
- any back office systems or organisations
- higher management
Successful identification of the stakeholders ensures that analysis will take into account the right elements
Literature
- {{cite book
| first = Steve | last = McConnell | authorlink = | year = 2001 | title = Rapid development: Taming wild software schedules | edition = 14th ed. | publisher = Microsoft Press | location = Redmond | id = 'ISBN' 1-556-15900-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 0596009488 | url = http://www.stellman-greene.com
}}
See also
- Business Process Reengineering
- Systems analysis
- Business Analysis
- Information technology
- Use cases
- Process modelling
- Data modelling
- Functional Requirements
- Non-Functional Requirements
- Model Driven Engineering
- Model Transformation Language
External links
- Requirements Engineering Process "Goodies"
- Author: Karl Weigers
- Abstract: This is a set of requirements engineering templates, checklists and guides made available by Karl Wiegers as a companion to his book, "Software Requirements" (Microsoft Press).
- Date: 2006
- Product Engineering Practices
- Authors: Andrew Stellman, Jennifer Greene
- Abstract: This is a page of product engineering templates and practices, including use cases, functional requirements and software requirements specification, from the companion site for their book, "Applied Software Project Management" (O'Reilly).
- Date: 2006
- What is Requirements Engineering?
- Authors: experts@requirements.in
- Abstract: This is a reviewed article that explains what Requirements Engineering is and how eminent researchers have described it.
- Date: 2006
- Adopting Requirements Visualization (PDF)
- META Group
- Date: 2004
- Application Definition Best Practices (PDF)
- Date: 2005
- Requirements Engineering: A Roadmap (PDF)
- Authors: B. Nuseibeh, S. Easterbrook
- Abstract: This paper presents an overview of the field of software systems requirements engineering (RE). It describes the main areas of RE practice, and highlights some key open research issues for the future.
- Date: 2000
- Guide to the Business Analysis Body of Knowledge
- IIBA President: Kathleen Barret
- Chair: Brenda Kerton
- Co-chair: Kevin Brennan
- Members: Barbara Carkenord, Gerrie Caudle, Kathleen Hass, Mary Gorman, Karen Mitchell, Cleve Pillifant, Dulce Oliveira
- Abstract: The Business Analyst Body of Knowledge represents the unique knowledge necessary for someone to be a successful business analyst. It sets an industry standard for practice and knowledge, and is maintained by BA practitioners with input from other stakeholders. Once complete, the BOK will form the basis of the accreditation program.
- Date: 2005
- Visualization for Start-up and Emerging Companies
- Author: Maurice Martin
- Abstract: This article describes how visualization is helping start-up and emerging companies improve their odds of success.
- Date: 2005
- Guide to the Software Engineering Body of Knowledge
- Project Champion: Leonard Tripp
- Executive Editors: Alain Abran, James W. Moore
- Editors: Pierre Bourque, Robert Dupuis
- Abstract: The objectives of the Guide to the Software Engineering Body of Knowledge project are to:
- characterize the contents of the Software Engineering Body of Knowledge;
- provide a topical access to the Software Engineering Body of Knowledge;
- promote a consistent view of software engineering worldwide;
- clarify the place of, and set the boundary of, software engineering with respect to other disciplines such as computer science, project management, computer engineering and mathematics;
- provide a foundation for curriculum development and individual certification and licensing material.
- Date: 2001
- Writing High Quality Requirement
- Author: Dr. Linda Rosenberg (SATC, NASA)
- Abstract: The requirements specification establishes the basis for all of the project's engineering management and assurance functions. If the quality of the requirements specification is poor, it can give rise to risks in all areas of the project. This workshop will educate project managers and software developers in effective development of quality requirement specifications. It will also provide them with ideas and methods they can incorporate immediately into their project plan and find a productive return in documentation evaluation and comprehension.
- Date: 1999
- Agile, Multidisciplinary Teamwork
- Author: Gautam Gosh
- Abstract: This article presents techniques and tools used to create requirements with a team composed of the different participants of agile projects.
- Date: 2004da:Kravspecifikation