1 Good Requirements Graphical Languages? Specification Qualities - - PDF document

▶
1
SMART_READER_LITE
LIVE PREVIEW

1 Good Requirements Graphical Languages? Specification Qualities - - PDF document

Jun 08, 2023 323 likes •368 views

REQUIREMENT SPECIFICATION The Basic Waterfall Model Today: Requirements Specification Requirements Requirements tell us what the system should do - specification not how it should do it. Analysis & Requirements are

slide-1
SLIDE 1

1

1.10.2004 Software Engineering 2004 Jyrki Nummenmaa 1

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.

1.10.2004 Software Engineering 2004 Jyrki Nummenmaa 2

The Basic Waterfall Model

Requirements specification Maintenance Testing Implementation Analysis & Design

1.10.2004 Software Engineering 2004 Jyrki Nummenmaa 3

Prototyping

Requirements

  • spec. - V&V

Maintenance

  • V&V

Testing - V&V Quick Implementa- tion - V&V Design - V&V

V&V = Verification and Validation

Quick Analysis & Design - V&V Implementation

  • V&V

1.10.2004 Software Engineering 2004 Jyrki Nummenmaa 4

Requirement specification – motivation and basics

  • Requirement specification is generally the most

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.

1.10.2004 Software Engineering 2004 Jyrki Nummenmaa 5

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.

1.10.2004 Software Engineering 2004 Jyrki Nummenmaa 6

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.

slide-2
SLIDE 2

2

1.10.2004 Software Engineering 2004 Jyrki Nummenmaa 7

Graphical Languages?

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

description

  • Data Flow diagrams for process description
  • Simple languages (like the above) work well in

practice

  • In requirement specification, they should be used

to model the application domain and the processes.

1.10.2004 Software Engineering 2004 Jyrki Nummenmaa 8

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?)

1.10.2004 Software Engineering 2004 Jyrki Nummenmaa 9

Overall Structure For Req. Spec. (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

1.10.2004 Software Engineering 2004 Jyrki Nummenmaa 10

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 …

1.10.2004 Software Engineering 2004 Jyrki Nummenmaa 11

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...)

1.10.2004 Software Engineering 2004 Jyrki Nummenmaa 12

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
slide-3
SLIDE 3

3

1.10.2004 Software Engineering 2004 Jyrki Nummenmaa 13

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.

1.10.2004 Software Engineering 2004 Jyrki Nummenmaa 14

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

1.10.2004 Software Engineering 2004 Jyrki Nummenmaa 15

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

1.10.2004 Software Engineering 2004 Jyrki Nummenmaa 16

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.

1.10.2004 Software Engineering 2004 Jyrki Nummenmaa 17

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).