REQUIREMENT Requirement specification SPECIFICATION motivation - - PDF document

▶
requirement requirement specification specification
SMART_READER_LITE
LIVE PREVIEW

REQUIREMENT Requirement specification SPECIFICATION motivation - - PDF document

May 25, 2023 212 likes •252 views

REQUIREMENT Requirement specification SPECIFICATION motivation and basics Today: Requirements Specification Requirement specification is generally a crucial phase of an Jyrki Nummenmaa University of Tampere, CS Department Jyrki

slide-1
SLIDE 1

1

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

REQUIREMENT SPECIFICATION

  • Today: Requirements Specification
  • Requirements tell us what the system should do - not how it

should do it.

  • Requirements are independent of the implementation tools,

programming paradigm, etc.

  • However, the requirements are then analysed with the

intended implementation methodology in mind.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

Requirement specification – motivation and basics

  • Requirement specification is generally a crucial phase of an

average software project - if it succeeds then a complete failure is unlikely.

  • The requirements specification can be used as a basis for a

contract.

  • The requirements specification can (and should) also be

eventually used to evaluate if the software fulfills the requirements.

  • As users generally can not work with formal specifications,

natural language specifications must or should often be used.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

Typical Documents

  • Basic textual document, e.g. according to the ANSI/IEEE

Standard 830 – will be discussed later.

  • A conceptual model of the domain, which may be already

available or built separately.

  • A description of the processes, e.g. a data flow diagram.
  • A textual description of the use cases – will be discussed

later.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

Formal Languages?

  • Usually much too difficult to understand even for an above

average user.

  • You may be able to verify the system, but how can you verify

the requirements?

  • They are usually used for critical well-defined systems and/or

concurrent processing, which is notoriously difficult to handle.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

Graphical Languages?

  • Examples:
  • Entity-Relationship (ER) model for conceptual

description

  • Data Flow diagrams for process description
  • These are, however, often more suitable for analysis and

design tasks.

  • Simple languages (like the above) work well in practice
  • In requirement specification, they should be used to model

the application domain and the processes.

  • If a domain conceptual model exists, it should be used to

accompany the requirements.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

Good Requirements Specification Qualities

  • Complete
  • Accurate
  • Unambiguous
  • Verifiable (How can you verify ”user friendliness”?)
  • Consistent
  • Modifiable (also the requirements change)
  • Traceable (where has each requirement come from?)
slide-2
SLIDE 2

2

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

Ansi/IEEE Standard 830

  • 1. Introduction

1.1. Purpose 1.2. Scope 1.3. Definitions, Acronyms and Abbreviations 1.4. References 1.5. Overview

  • 2. General Description

2.1. Product Perspective 2.2. Product Functions 2.3. User Characteristics 2.4. General Constraints 2.5. Assumptions and Dependencies

  • 3. Specific Requirements

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

ANSI/IEEE: Specific requirements

  • 3. Specific requirements

3.1. Functional Requirements 3.2. External Interface Requirements 3.3. Performance Requirements 3.4 Design Constraints 3.4.1. Standards Compliance 3.4.2. Hardware Limitations … 3.5. Attributes 3.5.1. Security 3.5.2. Maintainability … 3.6. Other Requirements 3.6.1. Data Base …

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

ANSI/IEEE: Specific requirements

  • 3. Specific requirements

3.1. Functional Requirements 3.2. External Interface Requirements 3.3. Performance Requirements 3.4 Design Constraints 3.4.1. Standards Compliance 3.4.2. Hardware Limitations … 3.5. Attributes 3.5.1. Security 3.5.2. Maintainability … 3.6. Other Requirements 3.6.1. Data Base …

  • 4. Extensions (acceptance criteria, other material...)

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

ANSI/IEEE: Functional Requirements

  • 3.1. Functional Requirements

3.1.1. Functional Requirement 1 3.1.1.1 Introduction 3.1.1.2 Inputs 3.1.1.3 Processing 3.1.1.4 Outputs 3.1.2 Functional Requirement 2 … 3.1.n Functional Requirement n

  • A typical way to express the requirements is ”The system

shall” – ”Järjestelmän on ...”

  • Use cases (coming later) describe functionalities

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

An Alternative Template

  • Go to Pressman’s book’s web pages

(http://www.pressman5.com) and from their choose ”professional resources” and then http://www.rspa.com and from there you can find work product templates. The one we are looking for is called ”System specification”.

  • Ok, you can go to rspa pages directly as well, but it may be a

good idea to check up pressman’s pages as well.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

Techniques For Getting The Requirements From Users

  • Asking
  • Interview
  • Questionnaire
  • ”Brainstorming” sessions
  • Analysing an existing system
  • We must understand how the new system will

differ from any old such system

  • Analysing the environment
  • e.g. process analysis
  • Prototyping
  • Gives best feedback and more formal

specifications but can be expensive

slide-3
SLIDE 3

3

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

What can go wrong? / 1

  • Missing specifications
  • Happens often
  • Experience helps
  • Sometimes it is impossible to notice
  • Contradictions
  • Do not document the same thing many times
  • Integrate different users’ views with the users
  • Sometimes the users disagree strongly.
  • Noise
  • Do not include material which does not contain

relevant information

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

What can go wrong? / 2

  • Documenting a solution rather than the problem
  • If the users know some information technology,

they want to start solving the problem as they express it.

  • Many formal (also graphical) methods tend to

direct the process into this.

  • Unrealistic requirements
  • Although we model the problem rather than the

solution, it is good to have some idea of what is possible.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

Who should do requirement specification?

  • Someone who can communicate with the users
  • Someone who has experience
  • Someone who knows similar systems and/or the application

area

  • Someone who knows what is possible and how (and how

much work is roughly needed).