• 3.1 Requirements analysis
• 3.2 Requirements types
• 3.3 Requirements elicitation techniques

3.1 Requirements analysis

Requirements analysis, also called requirements engineering, is the process of determining user expectations for a new or modified product. These features, called requirements, must be quantifiable, relevant and detailed. Capturing requirements analysis is an important phase of any SDLC-model. Formulating a useful set of requirements will require working closely with:

• Customers and users, so that everyone understands the requirements and their goals.
• Designers, so that they can construct a good design from the requirements specification.
• Testers, so that they can write test scripts to evaluate whether the implementation meets the requirements.
• Documentation writers, so that they can write user manuals from the specifications.

Any requirements document should include both functional and non-functional requirements. The functional requirements explain what the system will do, and the non-functional ones constrain the behavior in terms of safety, reliability, budget, schedule and other issues. Since mistakes made during the requirements process can cause additional problems later in the SDLC, the complete set of requirements should be validated by checking for completeness, correctness, consistency, realism, and other attributes. Measures reflecting requirements quality are especially important since they may indicate useful activities; e.g. when indicators show that the requirements are not well understood, prototyping of some requirements may be appropriate. 

There are many different types of definition and specification techniques that can be used for capturing requirements. Some are static (e.g. data flow diagrams), while others are dynamic (i.e. they include information about timing and time-related dependencies). We can also think of techniques as object oriented or procedural. The techniques that are used on a particular software development project should be chosen carefully, based on a number of factors. For example, the specification techniques differ in terms of their tool support, maturity, understandability, ease of use, and mathematical formality. Projects vary in terms of size and scope. The right technique must be chosen based on the needs of the current project, keeping these factors in mind. In some cases it may be desirable to use a combination of techniques to specify the different aspects of a system.

Because requirements typically contain many disparate elements that are integrated into a comprehensive whole, requirements must be written in a way that allows them to be linked and controlled. For example, a change to one requirement may affect other, related requirements, and the techniques and tools must support the changes to ensure that errors are caught early and quickly.

Common problems occur for almost all major software applications:

1. Requirements grow and change at rates in excess of 1 percent per calendar month.
2. Few applications include greater than 80 percent of user requirements in the first release.
3. Some requirements are dangerous or “toxic” and should not be included.
4. Some applications are overstuffed with extraneous features no one asked for.
5. Most software applications are riddled with security vulnerabilities.
6. Errors in requirements and design cause many high-severity bugs.
7. Effective methods such as requirement and design inspections are seldom used.
8. Standard, reusable requirements and designs are not widely available.
9. Mining legacy applications for “lost” business requirements seldom occurs.
10. The volume of paper documents may be too large for human understanding.

These ten problems are native to the software industry. Unlike the design of physical structures such as aircraft or buildings software does not utilize effective and proven design methods and standard document formats. In other words, if developer picks up the requirements or specifications for two different software applications, the contents and format are likely to be very different. These differences make validation difficult because without standard and common structures, there are far too many variations to allow easy editing or error identification. Automated verification of requirements and design are only theoretically possible now. Formal inspections of requirements and other documents are effective, but of course manual inspections are slower than automated verification.

There are also numerous “languages” for representing requirement and design features. These include use-cases, user stories, decision tables, fishbone diagrams, state-change diagrams, entity-relationship diagrams, the unified modeling language (UML), and perhaps 30 other flavors of graphical representation (flowcharts, Nassi-Schneiderman charts, data-flow diagrams, HIPO diagrams, etc.). For quality requirements, there are also special diagrams associated with quality function deployment (QFD).

Software engineers have a responsibility to help customers clear define requirements. A professional software engineer might insists on effective requirements methods such data mining of legacy applications, joint application design (JAD), quality function deployment (QFD), prototypes, and requirements inspections. It is also the responsibility of software engineers to alert clients to any potentially harmful requirements.

It is mistake to make assumption that users will be 100% effective in identifying requirements. User requirements are never complete and they are often wrong. The users of software applications are not software engineers and cannot be expected to know optimal ways of expressing and analyzing requirements. For a software project to succeed, requirements need to be gathered and analyzed in a professional manner, and software engineering is the profession that should know how to do this well.

3.2 Requirements types

According to ISO/IEEE 29148:2011 Requirement is statement which translates or expresses a need and its associated constraints and conditions.

As was pointed above all Requirements are divided into (ISO/IEEE 24765):

• Functional Requirement - a requirement that specifies a function that a system or its component must be able to perform (fig.3.1).
• Non Functional Requirement - a system requirement that describes not what the System will do but how the System will do it (fig.3.2).

Figure 3.1 — Functional Requirement

Non Functional Requirement, for example, software performance requirements, software external interface requirements, software design requirements (or design constraints), and quality attributes, are sometimes difficult to test, so they are usually evaluated subjectively.

Figure 3.2 — Non Functional Requirements

Requirements specification is a document containing any combination of recommendations, requirements or regulations to be met by a system. (ISO/IEEE 24765)

Stakeholder Requirements Specifications (StRS) - document which captures the System Operational Concept. The StRS may be written by one or more representatives of the supplier, one or more representatives of the Acquirer, or by both. (ISO/ IEEE 29148) (Stakeholder - individual or organization having a right, share, claim, or interest in a system or in its possession of characteristics that meet their needs and expectations. (ISO/IEEE 15288))

System Requirements Specifications (SyRS) - document which captures the structured collection of requirements (functions, performance, design constraints, and attributes) of the system to develop and its external interfaces.

A document used to assist in determining the completeness of requirements spesification is called Requirements traceability matrix (RTM) . Usually it is a table that links requirements to their origin and traces them throughout the project life cycle. (ISO/ IEEE 29148)

There are processes of Requirements Engineering:

• Requirements elicitation – the process through which the acquirers (customers or users) and the suppliers (contractor) of a system discover, review, articulate, understand, and document the users' needs and the constraints on the system and the development activity. (ISO/ IEEE 29148)
• Requirements validation - confirmation by examination that requirements (individually and as a set) define the right system as intended by the stakeholders. (ISO/ IEEE 29148)
• Requirements verification - confirmation by examination that requirements (individually and as a set) are well formed. (ISO/ IEEE 29148)

3.3 Requirements elicitation techniques

The two main sources of information for the requirements elicitation process are the users and the domain of application. But in market-driven software development requirements elicitation is more like requirements invention or problem-formulation, guided by marketing and sales considerations.

Asking . At the beginning of the project developers may simply ask the users what they expect from the system. Asking may take the form of an interview, a brainstorm, or a questionnaire. In an open-ended interview, the user freely talks about his tasks. This is the easiest form of requirements elicitation, but it suffers from user`s limitations and prejudices. In a structured interview, the analyst tries to overcome these by leading the user, for example through closed or probing questions. In discussion sessions with a group of users, some users are far more articulate than others, and thus have a greater influence on the outcome. To overcome this problem, a Delphi technique may be employed. The Delphi technique is an iterative technique in which information is exchanged in a written form until a consensus is reached. For example, participants may write down their requirements, sorted in order of importance. The sets of requirements thus obtained are distributed to all participants, who reflect on them to obtain a revised set of requirements. This procedure is repeated several times until sufficient consensus is reached.

Task analysis . is a technique to obtain a hierarchy of tasks and subtasks to be carried out by people working in the domain. Any of the other techniques discussed may be used to get the necessary information to draw this hierarchy. There are no clear-cut rules as to when to stop decomposing tasks. A major heuristic is that at some point users tend to ‘refuse’ to decompose tasks any further. Task analysis is often applied at the stage when the human-computer interaction component are being decided upon.

User Case analysis (Scenario-based analysis) . Instead of looking for generic plans as in interviews or task analysis, the analyst may study instances of tasks. A scenario is a story which tells how a specific task instance is executed. The scenario can be real or artificial. An example of a real scenario is that the analyst observes how a real employee handles an actual job activity. In real scenario real user verbalizes what he is doing and fixed it in an audio or video record. This think aloud method is a fairly unobtrusive technique to study people at work. It is often used to assess prototypes or existing information systems. Alternatively, software analyst may construct artificial scenarios and discuss these with the user. In fact, this story allows the user with an artificial mock-up version of the software to eventually be delivered. It serves as a prototype on a paper basis to better understand the requirements. If tied to UML type modelling, scenario analysis is often referred to as usage analysis. Scenarios and use cases are the most commonly used detection methods. Scenario analysis is often done in a somewhat random way. There is no way to tell if sufficient scenarios have been developed and It turns out quite accurate and complete picture of the requirements. Good scenarios are by no means easy. Although this may seem trivial: "just record the user episodes ", to ensure a good and reliable set scenarios.

Scenarios can be looked at from different perspectives. At the beginning the scenario lists a series of actions or events that together make up some episode. The focus then is on the process aspect, showing how the system proceeds through successive states. Alternatively, the same scenario may be looked at from a user perspective: how will the user interact with the system, what functionalities will she be offered? Yet another perspective is that the scenario leads to discussions about alternatives from which a certain choice has to be made.

Ethnography . A disadvantage of task analysis is that it considers individual tasks of individual persons, without taking into account the social and organizational environment in which these tasks are executed. In ethnography, groups of people are studied in their natural settings. Ethnographic methods are more likely to uncover implicit knowledge than most other elicitation techniques. User requirements can be studied by participating in their daily work for a period of time. The analyst becomes a scholar, accepting that the future users of the system are the real experts in their work.

Form analysis . A lot of information about the domain being modeled can often be found in various forms being used. Forms provide developers with information about the data objects of the domain, their properties, and their interrelations. They are particularly useful as an input to modeling the data aspect of the system.

Natural language descriptions . Like forms, natural language descriptions provide a lot of valuable information about the domain to be modeled. Often, natural language descriptions (and forms) provide the analyst with background information to be used in conjunction with other elicitation techniques such as interviews. Natural language descriptions tend to assume many implicit knowledge by the reader. A practical problem with natural language descriptions is that they are usually not kept up-to-date. Natural language descriptions are often taken as a starting point in object-oriented analysis techniques.

Derivation from an existing system . Starting from an existing system or looking at a number of systems in some application domain, software developers may formulate the requirements of the new system. This meta-requirements analysis process is known as domain analysis. Its goal generally is to identify reusable components, concepts, structures, and the like. In the context of requirements analysis, domain analysis can be viewed as a technique for deriving a ‘reference’ model for systems within a given domain. Such a reference model provides an architecture (skeleton) that can be adapted to fit the specific situation.

Prototyping. Given the fact that it is difficult, to build the good system from the start, software developers usually decide to use prototypes. Starting from a first set of requirements, a prototype of the system is constructed. This prototype is used for experiments, which lead to new requirements and more insight into the possible uses of the system. In one or more ensuing steps, a more definite set of requirements is developed. Other agile processes follow a similar strategy in which requirements are quickly translated into a working system to be assessed by its users.

During the requirements engineering phase often it is necessary to rethink the existing processes and procedures that concern software domain and sometimes to Reengineering Business Processes. Requirements which are gathered during understanding of business process are called ‘Business Requirement Specifications’ (BRS). Business processes should not be driven by information technology. Rather, information technology should enable them.

The primary goal of the requirements engineering phase is to elicit the contours and constituents of this fuzzy problem. This process is also known as conceptual modeling. During requirements engineering developers are modeling part of reality in which they are interested. It is referred to as the universe of discourse (UoD). The model constructed during the requirements engineering phase is an explicit conceptual model of the UoD. This model must be able to be communicated to the relevant people (such as analysts and users). To this end it should contain all relevant information from the UoD. One of the persistent problems of requirements analysis is to account for all of the relevant influences and leave out irrelevant details.