Principles Of Requirement Analysis And Design

Published Date: 02 Nov 2017

Introduction

In this lecture we define requirement analysis and design and present its principles, concepts and types. We present the activities of requirement analysis including identifying the customers, eliciting requirements (requirements gathering), requirement analysis and negotiation, and documenting requirements (software requirements specification). We also present the different types of requirements and requirement analysis techniques.

Learning Outcomes

Explain principles of system design

Explain steps, tasks, tools and activities that compose requirement analysis

Explain the nature of requirements specification.

1. Introduction

Requirements analysis is a method in software engineering that is used to distinguish the requirements of a software product. These requirements are determined and agreed upon by all stakeholders. This may not be as straightforward as one would think however, as is always the case, different stakeholders will have different requirements and needs that they want from the product.

Requirements analysis is an essential part of any software project in order for it to function properly and achieve the desired outcomes. Any requirement analysis carried out has to be documented, carried out in a way that makes it measurable and testable. Also, it has to be linked to a set of recognized business needs as well as being detailed enough for it to be used for system design.

In this lecture we define of requirement analysis and design and present its principles, concepts and types.

2. Overview of Requirements Analysis

Requirements analysis is also known as requirements engineering. It is also referred to as requirements gathering, requirements capture, or requirements specification.

Requirements analysis provides software designers with the opportunity to illustrate system information, the way the system functions and behaves into designs that take account the various components of the system.

Requirement analysis is concerned with determining the objectives, functions, and constraints of hardware and software systems. It begins with a feasibility study of the intended project, which leads to a feasibility report. If the feasibility study suggests that the intended project should be developed, then requirement analysis can begin.

Requirements analysis is used for understanding the customer needs and expectations from a proposed project/system where requirements are a description of how a project/system should behave. The system requirements are a description of system properties or attributes. They describe what a project/system is expected to do.

The requirements analysis is the responsibility of the project manager, program manager or business analyst, depending on the organizational hierarchy.

A software requirements specification (SRS) which results from requirement analysis is an inclusive illustration of system interaction. It depicts these interactions using use-cases which reveal all the possible interactions that can take place between the system and the user. These use-cases can also be described as ‘functional requirements’. Use cases also contain non-functional (or supplementary) requirements that are the requirements which impose constraints on the design or implementation including performance requirements, quality standards, and design constraints.

Requirements analysis is necessary at the beginning of a project as it ensures that the customer’s needs are explicitly identified and are worked towards throughout the system design. If requirements analysis is not done successfully and efficiently at the beginning or a project then the project becomes vulnerable and it will often not deliver the basic outcomes for which it is designed. Software companies invest time and resources into effective and streamlined requirements analysis which they carry out before the design process in order to establish the correct requirements and in order to support the business objectives of the end-user.

Requirements analysis includes the following activities/tasks:

Identify the customers

Eliciting requirements (requirements gathering)

Requirement analysis and negotiation

Documenting requirements

These activities/tasks of the requirements analysis are described in some detail in the following sub-sections.

2.1 Identify the Customers

Identifying the customers is the task of identifying who the users or customers of the project are. These customers are also referred to as the stakeholders. They represent people who are to be directly or indirectly affected by the new project. By defining the intended user is, the requirements analyst knows where he/she has to look for system requirements.

During the requirement analysis, management identifies all the stakeholders, their needs, and make sure they understand how the new product/system works and how it will affect them.

2.2 Eliciting Requirements (Requirements Gathering)

Requirement elicitation can be difficult because customers have system scope ambiguity, customer misunderstanding and the problem of dynamic requirements where requirements keep changing. The requirements elicitation process , includes tasks such as such assessing the business and technical feasibility of the requirements, identifying the stakeholders, defining the technical environment, identifying domain constraints, defining elicitation methods , and involving participation from many stakeholders, The software requirement specification produced as an output for the requirement elicitation process can be a statement of need and feasibility, a list of requirements with domain constraints, a set of usage scenarios or any prototypes to define requirements explicitly.

The requirements elicitation should focus on the customers to arrive at a valid requirements list. Eliciting requirements is the task of communicating with customers and users to determine and gather what their system requirements are. Information is gathered from the groups identified stakeholders. The requirements analyst draws out from each of these groups what their requirements from the project are and what they expect the project to accomplish. Requirements lists vary in detail and it all depends on two factors; Size of the stakeholder group and the size of the whole software project as a whole.

Problems of requirements elicitation include the following:

Ambiguous understanding of project tasks/activities/processes

Inconsistency within a single project task/activity/process by multiple customers

Insufficient input from stakeholders

Conflicting stakeholder interests

2. 3 Requirements Analysis and Negotiation

Requirement analysis and negotiation follows requirement gathering (eliciting). Analysis categorizes requirements and examines them for consistency, coverage, necessity, ambiguity, confliction, achievability and testability. Analyzing requirements is the task of determining whether the stated requirements are unclear, incomplete, or contradictory, and then resolving these problems to make the requirements clear, complete, non- contradictory.

A requirements analyst has to interact with multiple customers/stakeholders probably with conflicting requirements, to arrive at a clear consistent requirements list. Conflicts are reconciled by negotiation and impact of each requirement on project cost and delivery time is assessed. Using an iterative approach, requirements are either considered, eliminated, combined or updated/modified for the satisfaction of all stakeholders concerned.

2. 4 Documentation Requirements (Software Requirements Specification)

Documenting requirements which is also called Software Requirements Specification (SRS) is the requirement specification task which is the final step of requirement analysis done by the system and requirements development team. It describes all the function and performance of the system and the constraints associated with it. It also gives the complete description of the system to be developed. It can be a written document with a standard template, a prototype or use case.

Documenting requirements is the task of documenting and recording requirements in various forms, such as natural-language documents, UML models, or process specifications. One traditional way of documenting requirements is usually presented as a large contract style requirement list. The size of this list could reach hundreds of pages. Such lists are the traditional and classical way of presenting project requirements. This way of doing things has its drawbacks and has been recognized as ineffective to an extent. As an alternative to the large, requirement lists, requirements could be developed as user stories to define a requirement in everyday language. The new way of doing things is to create a requirements list and filter it down until the ‘business objectives’ of the new system are determined. Stakeholders and developers can then use requirements list to develop project goals and objectives. Then, they and conduct tests to measure project progress and project goals achievement. Project goals change more slowly than the list of requirements that is specific but unmeasured requirements.

After defining the small set of critical, measured goals, prototyping and iterative development phases may proceed to deliver actual project products and outcomes.

Advantages of using lists include the following:

A list provides a checklist of requirements.

A list provides a contract between the project stakeholders including sponsors and developers.

A list provides a high level description.

A list makes it easy to prioritize each individual item.

Disadvantages of using lists include the following:

A list can run to hundreds of pages which makes it difficult to read.

A list is an abstraction of all the requirements and hence, there is little context. This abstraction makes it impossible to see how the requirements fit or work together.

A list abstraction makes it difficult to prioritize requirements properly.

A list does not support and is not helpful in system design, since it does not lend itself to application.

The software requirements specification (SRS) is a document that lists all stakeholders’ needs and communicates these needs to the development team that will design and build the system. There are two types of requirements specifications documents:

User Requirements: They are written to aid all stakeholders in general but are particularly focused towards the end-users. They must be written in every-day-language in order for the end-users to understand it. It should also be free of any ambiguity to avoid un-necessary confusion.

System Requirements: They are written for the application development team and quality assurance and testing team. They are expressed as a programming or mathematical model.

3. Requirements Analysis Techniques

Once all stakeholder requirements are gathered, they are modeled. Then, a structured analysis of these requirements can be done. Some requirements analysis techniques used are "requirements animation", "automated reasoning", "knowledge-based critiquing", "consistency checking", "analogical and case-based reasoning".

Analysts can employ several techniques to elicit and gather the requirements from the customers and stakeholders. Classical techniques include holding interviews, or holding group discussions (workshops), questionnaires, surveys, and then creating requirements lists. However, there are new methods that are deemed to be more effective in handling the complexity of requirements identification. Methods such as prototyping, use cases, data flow diagrams, user interfaces, organizational charts and many more are used by software designers to tackle the task of requirements identification and analysis. Also, a new class of application simulation tools currently exist in the market that are used to bring the commercial users and the software development organizations closer together.

These application simulation tools offer the following:

E-whiteboards used for the drawing of diagrams such as application flows.

Ability to capture business logic and data needs.

Application simulations facilitate the creation of prototypes that act as a near-exact representation of the final product.

Interactivity

Capability to add contextual requirements and other comments.

Users who previously could not be involved in the design process, for example users who are not geographically connected, have the opportunity to try out/test new applications/systems.

System analyst could use these techniques to find out the requirements of the stakeholders, to meet the system business needs.

In the following sub-sections we present some of the above techniques in some detail.

3. 1 Stakeholder Interviews

Interviewing the stakeholders is a widespread method that is carried out in requirement analysis to obtain system information. They focus on the point of view of the stakeholder in order to find out their perception of the product. This allows the designers to understand how the product/system they are developing is seen by the stakeholder and what the various processes/tasks the stakeholder carries out when interacting with the product.

3. 2 Joint Requirements Development (JRD) Sessions

System/product requirements, in majority of most cases have "functional implications", which are not clearly discovered or not discovered at all using stakeholder interviews. As well as functional implications, some system requirements are also missed in interviews, which are identified using JRD sessions, which consist of stakeholders being placed in a supervised and controlled environment where they discuss the various requirements they want from the new product. As a result of this, new requirements are discovered (which can also be described as ‘joint requirements’) as well as the various functional implications associated with the stakeholders.

3. 3 Prototyping and Use Cases

Prototypes are models of the project/system. With prototype the users can have an early view of the application and hence this leads to fewer changes later. Prototyping is discussed in more detail in lecture 9. A use case is a technique for documentation of the requirements of a system or software change. Each use case provides one or more scenarios for describing the behavior of the system. These scenarios describe how the project/system will be used in specific situations. Use-cases are designed from the actor's point of view. They are written narratives that describe the role of an actor (user or device) as the interaction with the system occurs.

4. Types of Requirements

There are different types of requirements including customer requirements, functional requirements, performance requirements, design requirements, behavioral requirements, derived requirements, and allocated requirement. In order to design the new system, information obtained from methods that are used to identify customer, functional, and behavioral requirements is used.

The following sub-sections present common types of requirements categories.

4. 1 Customer Requirements

Customer requirements define the expectations customer's in terms of objective, environment, constraints and measure of effectiveness of the project/system. Customer requirements produce factual information regarding how they view that system. They help identify the following:

Operational set-up: At what location(s) will the system be installed and used by stakeholders?

Mission: What is the objective of the system? In other word, what is its mission and how will it achieve this?

Performance: What are the milestones and results that are needed to be achieved for comparison and evaluation against the objective of the system.

Utilization: The system will have many parts to it that make up the overall system. How will they be used?

Effectiveness: In order to achieve its objective, the system has to be functioning effectively. This effectiveness is measured.

Life Cycle: Once the system is live and being used by the user, how long will its life cycle be?

Environment: Similar to the operational set-up, this distinguishes the environments in which the system will effectively operate in.

4. 2 Architectural Requirements

Architectural requirements define system architecture that includes both structure and behavior of the system.

4. 3 Structural Requirements

Structural requirements define the system structure.

4.4 Behavioral Requirements

Behavioral requirements identify the behavior of the system. In other words, it identifies the way the system interacts with the user and the effect it will on the user.

4.5 Functional Requirements

Functional requirements define the tasks/activities of the system.

4.6 Non-Functional Requirements

This type of requirement focuses on the operation of the system, not the way it interacts with the user. It looks at the inside of the system rather than the interface.

4.7 Performance Requirements

Performance requirements define the expectation of the system mission in terms of the performance metrics such as quality, quantity, coverage, timeliness, and readiness.

4.8 Design Requirements

Design requirements define how the project/system processes are to be executed including building/designing the system, coding the applications and buying requirements for products.

4.9 Derived Requirements

Derived requirements are implied, derived, and transformed from a higher level requirement.

4.10 Allocated Requirements

Allocated requirements are established by breaking down a key requirement into many minor ones.

Summary

In this lecture we define requirement analysis and design and present its principles, concepts and types. We present the activities of requirement analysis including identifying the customers, eliciting requirements (requirements gathering), requirement analysis and negotiation, and documenting requirements (software requirements specification). We also present the different types of requirements and requirement analysis techniques.

Exercises

List the activities of requirement analysis.

What are the types of requirement analysis?

Define eliciting requirements activity.

Define software requirements specification.

Discuss three techniques of requirement analysis.

Why is it justified to use engineering approach in requirements analysis?