Software Engineering 2: Module 01

Requirements Engineering

The process of identifying, eliciting, analyzing, specifying, validating, and managing the needs and expectations of stakeholders for a software system.

Requirements Engineering

A systematic and strict approach to the definition, creation, and verification of requirements for a software system.

Requirements Engineering Process

To guarantee the effective creation of a software product, it entails several tasks that help in understanding, recording, and managing the demands of stakeholders.

Requirement

Varies in meaning across the software industry—from high level, abstract service descriptions to detailed, formal system functions.

Davis

In 1993, he explained the differences of requirements as arising from the varied perspectives and uses of requirements.

User Requirements

The high-level abstract requirements.

User Requirements

Statements, in a natural language plus diagrams, of what services the system is expected to provide to system users and the constraints under which it must operate.

System Requirements

The detailed description of what the system should do.

System Requirements

More detailed descriptions of the software system’s functions, services, and operational constraints.

System Requirements

Provide more specific information about the services and functions of the system that is to be implemented.

System Requirements Document

Should define exactly what is to be implemented.

Functional Specification

Another term for system requirements document.

System Stakeholders

Include anyone who is affected by the system in some way and so anyone who has a legitimate interest in it.

System Stakeholders

Ranges from end-users of a system through managers to external stakeholders such as regulators.

Feasibility Study

A short, focused study that should take place early in the RE process.

Does the system contribute to the overall objectives of the organization?

Can the system be implemented within schedule and budget using current technology?

Can the system be integrated with other systems that are used?

What are the three key questions that the feasibility study should answer?

Software System Requirements

Often classified as functional or non-functional requirements.

Functional Requirements

A type of software system requirement that describes what a system should do.

Functional Requirements

They outline the services it must provide, how it should respond to specific inputs, its behavior in various situations, and sometimes what the system must not do.

Non-functional Requirements

Define the limitations or conditions under which a system operates, typically applying to the entire system, not just specific features.

Timing constraints and development process constraints

Inclusions of Non-Functional Requirements

Domain Requirements

Derived from the application domain of the system rather than from the specific needs of system users.

Domain Requirements

Can be problematic when engineers lack domain knowledge.

Non-functional requirements influence the overall systems architecture.

A one non-functional requirement, like security, can lead to multiple functional requirements— adding new services or restricting existing ones.

Two Reasons Why Non-functional Requirements Implementation May Be Spread Throughout The System

Product requirements

Organizational requirements

External requirements

Types of Non-Functional Requirements

Product Requirements

These requirements specify or constrain the runtime behavior of the software.

Organizational Requirements

These requirements are broad system requirements derived from policies and procedures in the customer's and developer's organizations.

External requirements

This broad heading covers all requirements that are derived from factors external to the system and its development process.

1. Requirements discovery and understanding

2. Requirements classification and organization

3. Requirements prioritization and negotiation

4. Requirements documentation

Steps in Requirements Elicitation and Analysis Process

Requirements discovery and understanding

The process of interacting with stakeholders of the system to discover their requirements.

Requirements classification and organization

This activity takes the unstructured collection of requirements; groups related requirements organizes them into coherent clusters.

Requirements prioritization and negotiation

Inevitably, when multiple stakeholders are involved, requirements will conflict.

Requirements documentation

The requirements are documented and input into the next round of the spiral.

Viewpoint

A way of collecting and organizing a set of requirements from a group of stakeholders who have something in common.

Each of them includes a set of system requirements.

It might come from end-users, managers, or others.

Requirements Elicitation

Involves meeting with stakeholders of different kinds to discover information about the proposed system.

Interviewing

An approach where you talk to people about what they do to gather insights about the current system and the new system expectations.

1. Closed Interviews

2. Open Interviews

Two Types of Interviews

Closed Interviews

Interviews where the stakeholder answers a predefined set of questions.

Open Interviews

Interviews with no predefined agenda where the engineering team explores the range of system issues and hence to develop a better system that understand their needs.

1. You should be open-minded, avoid preconceived ideas about the requirements, and willing to listen to stakeholders.

2. You should prompt the interviewee to get discussions going by using a spring board question or a requirements proposal, or by working together on a prototype system.

Two Things to Become an Effective Interviewer

Observation or Ethnography

An approach where you watch people doing their job to see what artifacts they use and how they use them.

Ethnography

An observational technique that can be used to understand operational processes and help derive requirements for software to support these pro cases.

It can be combined with the development of a system prototype.

Ethnography

Informs the development of the prototype so that fewer prototype refinement cycles are required.

Ethnography

Helpful to understand existing systems, but this understanding does not always help with innovation. Innovation is particularly relevant for new product development.

Requirements for a Software System

Set out what the system should do and define constraints on its operation and implementation.

Functional Requirements

Statements of the services that the system must provide or are descriptions of how some computations must be carried out.

Non-Functional Requirements

Often constrain the system being developed and the development process being used.

Non-Functional Requirements

These might be product requirements, organizational requirements, or external requirements.

Non-Functional Requirements

They often relate to the emergent properties of the system and therefore apply to the system as a whole.

Requirements Engineering Process

Includes requirements elicitation, requirements specification, requirements validation, and requirements management.

Requirements elicitation

An iterative process that can be represented as a spiral of activities— requirements discovery, requirements classification and organization, requirements negotiation, and requirements documentation.