Course Title: Software Engineeringpmc.edu.np/department-of-statistics-and-computer... ·...

Course Title: Software Engineering

Course Contents

Unit-2:

1. Software Requirements

1.1. Introduction

1.2. Types of Requirements

1.3. Requirements Engineering Process

1.4. Feasibility study

1.5. Requirements elicitation and analysis

1.6. Requirement validation

1.7. Requirement management

Course Contents

Unit-2:

2. Software Prototyping

2.1. Introduction

2.2. Prototyping in the Software process

2.3. Rapid Prototyping Techniques

2.4. User Interface Prototyping

3. Formal Specification

3.1. Introduction

3.2. Formal Specification in Software Process

3.3. Interface Specification

3.4. Behavioural Specification

Let’s Start : Unit-2

Software Requirements?

Objectives:

⚫ To introduce the concepts of user and system

requirements for software system.

⚫ Explain different ways of expressing software

requirements.

⚫ To explain how software requirements may be

organised in a requirements document


Software requirements:

⚫ System requirements for a system are the

descriptions of the services provided by the system

and its operational constraints.

⚫ Need of customer for a system.

⚫ The process of finding out, analysing, documenting

and checking the services and constraints of system

is called Requirements Engineering (RE).

⚫ In some cases, a requirements is simply a high-level,

abstract statement of a service that the system should

provide or a constraint on the system.


What is requirements?

Requirements may serve a dual function

⚫ The requirements must be written so that several

contractors can bid for the contract, offerings,

meeting the client organisation’s needs.

⚫ Once awarded, the contractor must write a system

definition for the client in more details so that the

client understands and can validate what the software

will do.

Both of these documents may be called the requirements

document for the system.


Types of Requirement?

A software requirement can be of 3 types:

• Functional requirements

• Non-functional requirements

• Domain requirements


Functional Requirement?

A software requirement can be of 3 types:

• Functional requirements

• Non-functional requirements

• Domain requirements


Functional Requirement.

⚫ These are the requirements that the end user

specifically demands as basic facilities that the

system should offer.

⚫ All these functionalities need to be necessarily

incorporated into the system as a part of the contract.

⚫ These are represented or stated in the form of input to

be given to the system, the operation performed and

the output expected.

⚫ They are basically the requirements stated by the user

which one can see directly in the final product, unlike

the non-functional requirements.


Functional Requirement? Example

⚫ In a hospital management system, a doctor should be

able to retrieve the information of his patients.

⚫ Each high-level functional requirement may involve

several interactions or dialogues between the system

and the outside world. In order to accurately describe

the functional requirements, all scenarios must be

enumerated.

⚫ There are many ways of expressing functional

requirements e.g., natural language, a structured or

formatted language with no rigorous syntax and

formal specification language with proper syntax.


Non-Functional Requirement?

⚫ These are basically the quality constraints that the

system must satisfy according to the project contract.

⚫ The priority or extent to which these factors are

implemented varies from one project to other.

⚫ They are also called non-behavioral requirements.

⚫ Non-functional requirements may be more critical

than functional requirements. If these are not met, the

system is useless.



They basically deal with issues like:

⚫ Portability

⚫ Security

⚫ Maintainability

⚫ Reliability

⚫ Scalability

⚫ Performance

⚫ Reusability

⚫ Flexibility



NFR’s are classified into following types:

1. Product Requirements : These requirements specify

product behaviour. E.g Performance, memory,

reliability

2. Organisational Requirements: Derived from policies

and procedures in the customer’s and developer’s

organisation.

3. External Requirements: Requirements that are

derived from factors external to the system and its

development process.


Examples of Functional & Non-Functional

Requirement?

⚫ See file for Functional & Non-Functional

• <02 SRS Example document- Amazing Restaurant Finder>

⚫ Also see files for sample of writing SRS

Document:

• 00 How to write SRS document

• 01 SRS Template IEEE Standard


Domain Requirements?

⚫ Domain requirements are derived from the

application domain of the system rather than

from the specific needs of the system users.

⚫ Domain requirements are important because

they often reflect fundamentals of the

application domain. Example of library system:

User interface of library databases should be

based on the Z39.50 standard.

Don’t let the book to print because of the

copyright restriction.


Domain requirements problems?

Understandability:

⚫ Requirements are expressed in the language of

the application domain.

⚫ This is often not understood by software

engineers developing the system.

Implicitness:

⚫ Domain specialists understand the area so well

that they do not think of making the domain

requirements explicit.


Level of Description of Requirement?

1. User Requirements

2. System requirements

1. User Requirements:

⚫ High level abstraction requirements.

⚫ Requirements are statements, in a natural language plus

diagram of what services the system is expected to provide

and the constraints under which it must operate.

⚫ The user requirements for a system should describe the

functional and non-functional requirements so that they are

understandable by system users without detailed technical

knowledge.


1. User Requirements:

Guidelines for writing requirements.

To minimize misunderstanding in user requirements, follow

guidelines as:

⚫ Invent a standard format and use it for all Requirements

⚫ Use language in a consistent way. Use shall for mandatory

requirements, should for desirable requirements

⚫ Use text highlighting to identify key parts of the requirement

⚫ Avoid the use of computer jargon


2. System requirements:

⚫ More detailed specifications of user requirements

⚫ Serve as a basis for designing the system

⚫ May be used as part of the system contract

⚫ System requirements may be expressed using system

models.


2. System requirements: (Requirements and design)

⚫ In principle, requirements should state what the

system should do and the design should describe

how it does this.

⚫ In practice, requirements and design are inseparable

• A system architecture may be designed to structure the

requirements

• The system may inter-operate with other systems that

generate design requirements

• The use of a specific design may be a domain requirement


2. System requirements:

⚫ System requirements set out the system’s functions,

services and operational constraints in details.

⚫ The system requirements documents ( Functional

specification) should be precise.

⚫ It should define exactly what is to be implemented.

⚫ It may be part of the contract between the system

buyer and the software developers.


⚫ Example:

⚫ User Requirement Definition

1. The MHC-PMS shall generate monthly management

reports showing the cost of drugs prescribed by each

clinic during that month.

⚫ System Requirements Specification

1. On the last working day of each month, a summary of

the drugs prescribed, their cost, and the prescribing

clinics shall be generated.

2. The system shall automatically generate the report for

printing after 17.30 on the last working day of the

month.


⚫ Readers of different levels of requirements:


Interface requirements:

⚫ A point where two systems, subjects, organisations

etc. meet and interact.

⚫ A device or program enabling a user to communicate

with a computer

⚫ A interface is a intersection between system and

environment.

⚫ Interface = system/environment



⚫ All software systems must operate with existing

systems that have already been implemented and

installed in an environment.

⚫ If the new system and existing systems must work

together, the interfaces of existing systems have to be

precisely specified.

⚫ These specifications should be defined early in the

process and included in the requirements documents.



⚫ Three types of interface may have to be defined

• Procedural interfaces

• Data structures that are exchanged

• Data representations

Formal notations are an effective technique for interface

specification


The software requirements documents:

⚫ The software requirements documents ( also called

Software Requirements Specification or SRS) is the

official statement of what the system developers

should implement.

⚫ Include both the user requirements for a system and a

detailed specifications of the system requirements.


Users of a requirements document:


Requirements document structure:

• Introduction

• Glossary

• User requirements definition

• System architecture

• System requirements specification

• System models

• System evolution

• Appendices

• Index



1. Introduction1.1 Purpose of the requirements document

1.2 Scope of the product

1.3 Definitions, acronyms and abbreviations

1.4 References

1.5 Overview of the reminder of the document

2. General Description2.1 Product perspective

2.2 Product functions

2.3 User characteristics

2.4 General constraints

2.5 Assumptions and dependencies



3. Specific Requirements3.1 Functional requirements

3.2 Non- Functional requirements

3.3 Interface Requirements

………

Most substantial part of the documents but because of the wide

variability in organisational practices, it is not appropriate to

define a standard structure for this section.

The requirements may document external interfaces, describe

system functionality and performance, specify logical database

requirements, design constraints, emergent system properties and

quality characteristics.



4. Appendices : Appendices contain material that is too detailed to

include in the main report, such as long mathematical

derivations or calculations, detailed technical drawings

etc

5. Index : An alphabetical list of names, subjects, etc. with

reference to the pages on which they are mentioned.

Course Contents

Unit-2:

1. Software Requirements

1.1. Introduction

1.2. Types of Requirements

1.3. Requirements Engineering Process

1.4. Feasibility study

1.5. Requirements elicitation and analysis

1.6. Requirement validation

1.7. Requirement Management

Requirements Engineering

Requirements Engineering Process

Requirements Engineering Process:

1. Feasibility study

2. Requirements elicitation and analysis

3. Requirements validation

4. Requirements management




⚫ Requirements engineering (RE) refers to the

process of defining, documenting, and maintaining

requirements in the engineering design process.

⚫ Requirement engineering provides the appropriate

mechanism to understand what the customer

desires, analysing the need, and assessing

feasibility, negotiating a reasonable solution,

specifying the solution clearly, validating the

specifications and managing the requirements as

they are transformed into a working system.




⚫ Thus, requirement engineering is the disciplined

application of proven principles, methods, tools,

and notation to describe a proposed system's

intended behaviour and its associated constraints.




It is a four-step process, which includes –

1. Feasibility Study

2. Requirement Elicitation and Analysis

3. Software Requirement Specification

4. Software Requirement Validation

⚫ Software Requirement Management




It is a four-step process, which includes –



1. Feasibility study:

The objective behind the feasibility study is to

create the reasons for developing the software

that is acceptable to users, flexible to change

and conformable to established standards.



Type of Feasibility study:

1. Technical Feasibility - Technical feasibility evaluates

the current technologies, which are needed to

accomplish customer requirements within the time and

budget.

2. Operational Feasibility - Operational feasibility

assesses the range in which the required software

performs a series of levels to solve business problems

and customer requirements.

3. Economic Feasibility - Economic feasibility decides

whether the necessary software can generate financial

profits for an organization.



Feasibility study implementation:

Based on information assessment (what is required),

information collection and report writing.

Questions for people in the organisation

⚫ What if the system wasn’t implemented?

⚫ What are current process problems?

⚫ How will the proposed system help?

⚫ What will be the integration problems?

⚫ Is new technology needed? What skills?

⚫ What facilities must be supported by the proposed

system?



2. Requirement Elicitation and Analysis:

In this stage, SW engineers work with customers and

system end-users to find out about the application

domain, what services the system should provide, the

required performance of the system, hardware

constraints and so on.

⚫ What is Requirement Elicitation and Analysis and

what need to do in this phase?

⚫ Problems of Elicitation and Analysis ?

⚫ Elicitation and Analysis Process ?




This is also known as the gathering of requirements.

Here, requirements are identified with the help of

customers and existing systems processes, if

available.

Analysis of requirements starts with requirement

elicitation. The requirements are analysed to identify

inconsistencies, defects, omission, etc. We describe

requirements in terms of relationships and also resolve

conflicts if any.




Requirements Engineering Activities

Stakeholder

Participants




Requirement as "something that governs what, how well,

and under what conditions a product will achieve a given

purpose."

Functional requirements define "what" the system must

do, performance requirements define "how well" the

system must perform its functions, and a variety of other

requirements define "under what conditions" the system

must operate.

Requirements engineering covers all of the activities

needed to define and manage requirements shown in

above Figure.




Elicit means to evoke a response. You will have to do

some work to draw out the requirements from the

stakeholders and any existing documentation.

Analyse means to study or examine something in detail,

in order to discover more about it.

There are many different elicitation techniques that can

be used and are as follows:

• Viewpoints

• Interviewing

• Scenarios and Use-case

• Ethnography




⚫ Requirements elicitation also called requirements

discovery

⚫ Involves technical staff working with customers to

find out about the application domain, the services

that the system should provide and the system’s

operational constraints

⚫ May involve end-users, managers, engineers

involved in maintenance, domain experts, trade

unions, etc. These are called stakeholders




Problems of Elicitation and Analysis:

⚫ Getting all, and only, the right people involved.

⚫ Stakeholders don’t know what they really want

⚫ Stakeholders express requirements in their own terms

⚫ Different stakeholders may have conflicting requirements

⚫ Organisational and political factors may influence the system

requirements

⚫ The requirements change during the analysis process. New

stakeholders may emerge and the business environment

change




Elicitation and Analysis Process:




Requirements analysis process activities:

⚫ Domain understanding

⚫ Requirements collection

⚫ Classification

⚫ Conflict resolution

⚫ Prioritisation

⚫ Requirements checking




System models:

⚫ Different models may be produced during the

requirements analysis activity

⚫ Requirements analysis may involve three structuring

activities which result in these different models

• Partitioning: Identifies the structural (part-of)

relationships between entities

• Abstraction: Identifies generalities among entities

• Projection: Identifies different ways of looking at a

problem




Details of different elicitation techniques:

⚫ Viewpoints

⚫ Interviewing

⚫ Scenarios (Use-case diagram)

⚫ Ethnography




Viewpoint-oriented elicitation:

⚫ Stakeholders represent different ways of looking at a

problem or problem viewpoints

⚫ This multi-perspective analysis is important as there

is no single correct way to analyse system

requirements

⚫ Viewpoint analysis is that it can help recognize

different perspectives and provides a way for

discovering any possible conflicts in the requirements

proposed by different stakeholders.




Viewpoints:

A viewpoint is a collection of patterns, templates, and

conventions for constructing one type of view. It defines

the stakeholders whose concerns are reflected in the

viewpoint and the guidelines, principles, and template

models for constructing its views.

The example used here is an auto-teller system which

provides some automated banking services. Services include

cash withdrawal, message passing (send a message to

request a service), ordering a statement and transferring

funds.




Auto-teller viewpoints:

⚫ Bank customers

⚫ Representatives of other banks

⚫ Hardware and software maintenance engineers

⚫ Marketing department

⚫ Bank managers and counter staff

⚫ Database administrators and security staff

⚫ Communications engineers

⚫ Personnel department




Three Generic types of viewpoint:

1. Interactor viewpoints

People or other system that interact directly with the system

2. Indirect viewpoints

Who don’t use the system but influence the requirements i.e.

in the ATM system, management and security staff.

3. Domain viewpoints

Domain characteristics and constraints that influence the

system requirements. In the bank ATM system, standards for

interbank communications.




Viewpoint-oriented method (VORD):

⚫ VORD are used to identify the different user classes

and their viewpoints.

⚫ VOID is widely used approach to requirements

analysis




Viewpoint Oriented Requirement Definition (VORD):

⚫ Viewpoint identification

Discover viewpoints which receive system services and identify

the services provided to each viewpoint

⚫ Viewpoint structuring

Group related viewpoints into a hierarchy. Common services are

provided at higher-levels in the hierarchy

⚫ Viewpoint documentation

Refine the description of the identified viewpoints and services

⚫ Viewpoint-system mapping

Transform the analysis to an object-oriented design (i.e. use case)




VORD standard forms:




Scenarios:

⚫ Scenarios are descriptions of how a system is

used in practice

⚫ They are helpful in requirements elicitation as

people can relate to these more readily than

abstract statement of what they require from a

system

⚫ Scenarios are particularly useful for adding

detail to an outline requirements description




Scenario descriptions:

⚫ System state at the beginning of the scenario

⚫ Normal flow of events in the scenario

⚫ What can go wrong and how this is handled

⚫ Other concurrent activities

⚫ System state on completion of the scenario




Event scenarios:

⚫ Event scenarios may be used to describe how a

system responds to the occurrence of some

particular event such as ‘start transaction’

⚫ VORD includes a diagrammatic convention for

event scenarios.• Data provided and delivered

• Control information

• Exception processing

• The next expected event




Event scenario - start transaction:




Scenario: Notation for data and control analysis:

⚫ Ellipses. data provided from or delivered to a

viewpoint

⚫ Control information enters and leaves at the

top of each box

⚫ Data leaves from the right of each box

⚫ Exceptions are shown at the bottom of each

box

⚫ Name of next event is in box with thick edges




Scenario: Exception description:

⚫ Most methods do not include facilities for

describing exceptions

⚫ In this example, exceptions are• Timeout. Customer fails to enter a PIN within the allowed

time limit

• Invalid card. The card is not recognised and is returned

• Stolen card. The card has been registered as stolen and is

retained by the machine




Use cases:

⚫ Use-cases are a scenario based technique in the UML

which identify the actors in an interaction and which

describe the interaction itself

⚫ A set of use cases should describe all possible

interactions with the system

⚫ Sequence diagrams may be used to add detail to use-

cases by showing the sequence of event processing

in the system




Use cases: Describing a Use Case

The description should include:

⚫ The name of the use case, which should summarize

its purpose

⚫ The actor or actors

⚫ The flow of events

⚫ Assumptions about entry conditions




Use cases: Describing a Use Case




Social and organisational factors:

⚫ Software systems are used in a social and

organisational context. This can influence or even

dominate the system requirements

⚫ Social and organisational factors are not a single

viewpoint but are influences on all viewpoints

⚫ Good analysts must be sensitive to these factors but

currently no systematic way to tackle their analysis




Ethnography: Social and organisational factors

Consider a system which allows senior management to

access information without going through middle

managers

• Managerial status. Senior managers may feel that they are

too important to use a keyboard. This may limit the type of

system interface used

• Managerial responsibilities. Managers may have no

uninterrupted time where they can learn to use the system

• Organisational resistance. Middle managers who will be

made redundant may deliberately provide misleading or

incomplete information so that the system will fail




Ethnography:

⚫ Ethnography is an observational technique that can

be used to understand social and organisational

requirements.




Ethnography:

⚫ A social scientists spends a considerable time

observing and analysing how people actually work

⚫ People do not have to explain or articulate their work

⚫ Social and organisational factors of importance may

be observed

⚫ Ethnographic studies have shown that work is usually

richer and more complex than suggested by simple

system models




Ethnography effective for 2 types of requirements:

1. Requirements that are derived the way in which

people actually work rather than the way in which

process definitions say they out to work.

2. Requirements that are derived from cooperation and

awareness of other people’s activities.




Focused ethnography:

⚫ Combines ethnography with prototyping

⚫ Prototype development results in unanswered

questions which focus the ethnographic analysis

⚫ Problem with ethnography is that it studies existing

practices which may have some historical basis which

is no longer relevant




Ethnography and Prototyping:



3. Software Requirement Specification:

⚫ Software requirement specification is a kind of

document which is created by a software analyst

after the requirements collected from the various

sources - the requirement received by the customer

written in ordinary language.

⚫ It is the job of the analyst to write the requirement in

technical language so that they can be understood

and beneficial by the development team.

⚫ The models used at this stage include ER diagrams,

data flow diagrams (DFDs), Use-case diagram, data

dictionaries, etc.




⚫ Data Flow Diagrams: Data Flow Diagrams (DFDs)

are used widely for modelling the requirements.

DFD shows the flow of data through a system. The

system may be a company, an organization, a set of

procedures, a computer hardware system, a

software system, or any combination of the

preceding. The DFD is also known as a data flow

graph or bubble chart.




⚫ Data Dictionaries: Data Dictionaries are simply

repositories to store information about all data

items defined in DFDs. At the requirements stage,

the data dictionary should at least define customer

data items, to ensure that the customer and

developers use the same definition and

terminologies.




⚫ Entity-Relationship Diagrams: Another tool for

requirement specification is the entity-relationship

diagram, often called an "E-R diagram." It is a

detailed logical representation of the data for the

organization and uses three main constructs i.e.

data entities, relationships, and their associated

attributes.



4. Software Requirement Validation:

⚫ After requirement specifications developed, the

requirements discussed in this document are

validated. The user might demand illegal,

impossible solution or experts may misinterpret the

needs.

⚫ Requirements error costs are high so validation is

very important

• Fixing a requirements error after delivery may cost up to 100

times the cost of fixing an implementation error




Requirements checking:

⚫ Validity. Does the system provide the functions

which best support the customer’s needs?

⚫ Consistency. Are there any requirements conflicts?

⚫ Completeness. Are all functions required by the

customer included?

⚫ Realism. Can the requirements be implemented

given available budget and technology

⚫ Verifiability. Can the requirements be checked?




Requirements validation techniques:

⚫ Requirements reviews:

⚫ Prototyping: Using an executable model of the

system to check requirements.

⚫ Test-case generation: Developing tests for

requirements to check testability.

⚫ Automated consistency analysis: checking for the

consistency of structured requirements descriptions.




Requirements reviews:

⚫ Regular reviews should be held while the

requirements definition is being formulated

⚫ Both client and contractor staff should be involved

in reviews

⚫ Reviews may be formal (with completed documents)

or informal. Good communications between

developers, customers and users can resolve

problems at an early stage




Review checks:

⚫ Verifiability. Is the requirement realistically testable?

⚫ Comprehensibility. Is the requirement properly

understood?

⚫ Traceability. Is the origin of the requirement clearly

stated?

⚫ Adaptability. Can the requirement be changed

without a large impact on other requirements?



5. Software Requirement Management:

⚫ Requirements management is the process of

managing changing requirements during the

requirements engineering process and system

development.

⚫ Requirements are inevitably incomplete and

inconsistent

• New requirements emerge during the process as business

needs change and a better understanding of the system is

developed

• Different viewpoints have different requirements and these are

often contradictory




Requirements change:

⚫ The priority of requirements from different

viewpoints changes during the development

process

⚫ System customers may specify requirements from a

business perspective that conflict with end-user

requirements

⚫ The business and technical environment of the

system changes during its development




Requirements evolution:




Enduring and volatile requirements:

⚫ Enduring requirements: Stable requirements

derived from the core activity of the customer

organisation. E.g. a hospital will always have

doctors, nurses, etc. May be derived from domain

models

⚫ Volatile requirements: Requirements which change

during development or when the system is in use. In

a hospital, requirements derived from health-care

policy




Classification of requirements:

⚫ Mutable requirementsRequirements that change due to the system’s environment

⚫ Emergent requirementsRequirements that emerge as understanding of the system develops

⚫ Consequential requirementsRequirements that result from the introduction of the computer system

⚫ Compatibility requirementsRequirements that depend on other systems or organisational

processes




Requirements management planning:

⚫ During the requirements engineering process, you

have to plan:

Requirements identification

» How requirements are individually identified

A change management process

» The process followed when analysing a requirements change

Traceability policies

» The amount of information about requirements relationships that is

maintained

CASE tool support

» The tool support required to help manage requirements change




Traceability:

⚫ There are relationship between the requirements, the

source of those requirements, and the system design

that should be recorded and how these records should

be maintained. Traceability maintained all these

information in a matrix tabular form and is called

traceability.

⚫ Traceability is the property of a requirements

specification that reflects the ease of finding related

requirements.

⚫ Traceability is used to track the requirements changes




Traceability:

There are 3 types of traceability information that may

be maintained.

1. Source traceability information – Who (Stakeholder)

proposed the requirements

2. Requirement traceability information: Dependent

requirements within the requirements document

3. Design traceability information: Links the

requirements to the design modules where these

requirements are implemented.




Requirement Change management:

There are 3 types principle stages to a change

management process:

1. Problem analysis and change specification

2. Change analysis and costing

3. Change implementation

Course Title: Software Engineeringpmc.edu.np/department-of-statistics-and-computer... ·...

Documents

Transcript of Course Title: Software Engineeringpmc.edu.np/department-of-statistics-and-computer... ·...