Difference between revisions of "Requirements"

Latest revision as of 21:18, 14 November 2013

Requirements analysis is a term used to describe all the tasks that go into the instigation, scoping and definition of a new or altered computer system. Requirements analysis is an important part of the software engineering process; whereby business analysts 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 it has been considered to be a relatively easy part of the process. 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.

Requirements are a definition of the features that the system is required to implement and the constraints under which it is required to operate. For example:

• The system shall maintain records of all library materials including books, serials, newspapers and magazines, video and audio tapes, reports, collections of transparencies, computer disks and CD-ROMs.
• The system shall allow users to search for an item by title, author, or by ISBN.
• The systems user interface shall be implemented using a World-Wide-Web browser.
• The system shall support at least 20 transactions per second.
• The system facilities which are available to public users shall be demonstrable in 10 minutes or less.
• The system should be developed using Java

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:

• feasible
• schedulable
• affordable
• legal
• ethical

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 engineering.

Among all problems pertaining to software engineering, requirements are the cause of the greatest number of problems. Each requirement problem is extremely costly to solve, because they represent a flaw in the understanding of the problem to be solved by the software. Requirements problems are likely to be uncovered late in the development of the system. The later a requirements problem is uncovered, the greatest will be the cost associated with its resolution. Requirements are also very likely to change in the course of the project, leading to problems despite apparently commplete requirements in the beginning.

Most of these problems come from misunderstandings between customers, those developing the system requirements and software engineers developing or maintaining the system. Great effort has to be put on gathering a complete set of requirements as soon as possible in the development of the system. The main problem in requirements gathering is a communication problem. It is not a computer science problem, and it cannot be tackled with any sound, provable theory. For example, it is impossible to formally prove that all requirements are reflecting the real user’s needs. That fuzzy nature of requirements gathering makes it a very weak link in the chain of software development activities. Unfortunately, requirements gathering is also one of the most important (if not the most important) phase of software development, because it determines what is the nature of the software to be developed. All subsequent phases of development are based on the requirements. If requirements are wrong, the software developed might be the best piece of software ever written, but it won’t satisfy the client, which make the whole thing useless.

General problems

The general difficulties involved with requirements analysis are increasingly well known:

• identification of the right sources of information is itself a difficult task.
• 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.
• 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.
• the input to this phase (i.e. people's ideas and needs) is informal so by definition no formal tool or technique can verify its output versus the input.

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 might express what they want, but that might not coincide with what they actually need.
• Users won't commit to a set of written requirements, and will change their mind later.
• 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 most often technically unsophisticated.
• Users don't understand the software development process.

Developer issues

However, developers are equally at blame. Typical problems caused by software developers are:

• Software developers and the end user 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 belongs to the developers, since that is what they are being paid to do.
• 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.

Human and Social Factors

The requirements engineering process is dominated by human, social and organizational factors because they always involve a range of stakeholders from different backgrounds and with different individual and organizational goals. System stakeholders may come from a range of technical and non-technical background and from different disciplines. Some of the factors influencing requirements are:

• Personality and status of stakeholders.
• Personal goals of individuals within an organization.
• Degree of political influence of stakeholders within an organization.

For example, upper management will tend to impose their view on end users, thus occulting a very important part of the necessary system needs. Also, when determining the important stakeholders, shy and/or overworked but experienced people will tend not to be present, even though their input is of prime importance. On the contrary, outspoken, ambitious and sometimes inexperienced people will provide lots of non-valuable input. Factors like this are very hard to detect and rather fall into the domain of psychology than computer science or engineering, thus requiring very specialized people to deal with.

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 proved difficult to find staff who possess equally good people and technical skills. In addition, the techniques used to analyse requirements have not proved sufficiently effective.

Modern techniques introduced in the 1990s like prototyping, the UML, the use case approach, and agile software development seem to offer more promise. More recently, a new class of application simulation or application definition tools have entered the market. These tools serve to bridge the communication gap between business users and the IT organization - and also serve to increase innovation and creativity by allowing 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

Requirements Process

Any activity that is of great importance in a process can itself be the topic of a sub-process. We have shown that Requirements Engineering is a very complex problem, and here we define a generic process for Requirements Engineering. Without a proper requirements engineering process, many things can go wrong in a project, for example:

• Projects go over budget and/or take longer time than first predicted.
• People involved in system analysis complain that they do not have enough time or resources to do their job properly.
• Requirements documents are often not understandable or incomplete.
• The system design process suffers from rework due to requirements errors or incompleteness.
• Resulting systems lack some functionalities or have unused functionalities.
• System maintenance costs goes skyrocket.
• The cost of system changes/improvement is hard to evaluate.

Requirements Process Items

Any process can be described as a set of activities, artifacts (inputs, and outputs) and roles. The Requirements Engineering Process can be described as:

Activities

Requirements Elicitation

Requirements are discovered through consultation with stakeholders, using techniques such as interviews, workshops and questionnaires.

Requirements Analysis

Requirements are analyzed as to identify and resolve overlaps or contradictions between requirements, as wel las to identify their respective priorities, risks, and cost. Stakeholder input is still a key aspect in requirements analysis, as negociation between contradictory stakeholders is very likely, and the input of experts is paramount to risk and cost assessment.

Requirements Documentation

A clear, concise and complete requirements document is produced, normally following pre-established document standard.

Requirements Validation

The requirements document is checked for consistency and completeness.

Artifacts

Inputs:

• Users needs.
• Application domain information and jargon.
• Existing system information and documentation.
• Existing business model.
• Application domain regulations and standards, etc.

Output:

• A general statement of the problem to be solved.
• Agreed set of requirements and constraints.
  • Traceability matrix depicting the dependencies between requirements.
  • Prioritization of requirements.
  • Risk assessment on requirements.
  • Cost assessment of individual requirements.
• Business model of the application domain.

Roles

The roles (or stakeholders) in a process are the people involved in the execution of that process, be it for providing input for the problem description, contributing to the elaboration of various models, analyzing requirements, writing documents, validation, etc. Simply speaking, requirements engineering involves actors who are primarily interested in the problem to be solved (end-users, etc) as well actors interested in the solution (system designers, etc.). Stakeholders are normally identified by their roles rather than individually, for example, a large software system might potentially be used by thousands of users, but these can generally be categorized in few kinds of users, which represent different kinds of stakeholders. Examples of stakeholders:

• Software engineers responsible for system development
  • Designers
  • Programmers
  • Project managers
• System end-users who will use the system after it has been delivered
• Managers of system end-users who are responsible for their work
• External regulators who check that the system meets e.g. its legal requirements
• Domain experts who give essential background information about the system application domain

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 a while, 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, make sure you 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 talking, and important needs are overlooked when the system is implemented; and/or
• there is not enough descriptive feedback, 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) and creating requirements lists. More modern techniques include prototyping, and use cases. Hopefully, via a process employing many of these methods, the exact requirements of the stakeholders will be established, 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 the time and cost; but more importantly almost always this reveals major discrepancies with regard to how the existing business process works and how it should work in the future. Also different users might have differing or even contradictory requirements.

Requirement workshops

Therefore where systems are complex the usual method is to use requirement workshops, where the analyst brings the main stakeholders in the system together in order to analyse the system and develop the solution.

Such workshops are ideally carried out off site, so that the stakeholders are not distracted. They usually have a facilitator to keep the process focused, a scribe to document the discussion, and usually make use of a projector and diagramming software. 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

The most common 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 (ie 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 approach

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.

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 orientated 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
• have no implementation-specific language
• 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.

Stakeholder identification

A major new emphasis in the 1990s has been 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

References

• Wikipedia:Software Requirements Specification
• Peter Grogono's SOEN341 lecture notes, 2000.
• Steve McConnell: Rapid development. Taming wild software schedules. 14th ed. Microsoft Press, Redmond 2001 ISBN 1-556-15900-5