Download Software Engineering: Characteristics of Good Requirements Definition & Specification and more Study Guides, Projects, Research Software Engineering in PDF only on Docsity!

Copyright © K.Goseva 2006 CS 230 Introduction to Software Engineering Slide 1

REQUIREMENTS

DEFINITION &

SPECIFICATION

Copyright © K.Goseva 2006 CS 230 Introduction to Software Engineering Slide 2

Requirements definition and specification

• Must correctly define all of the software

requirements, but no more

• Should not describe any design, verification, or

project management details, except for required

design constraints

Copyright © K.Goseva 2006 CS 230 Introduction to Software Engineering Slide 3

Characteristics of Good RD&S

• Unambiguous

• Complete

• Verifiable

• Consistent

• Modifiable

• Traceable

• Usable during the operation and maintenance

phase

Copyright © K.Goseva 2006 CS 230 Introduction to Software Engineering Slide 4

Characteristics of Good RD&S (Contd)

• Unambiguous
  • Every requirement has only one interpretation
  • Each characteristic is described using only one term
  • Example of ambiguous requirement: All customers have the same control field

a) All customers have the same value in their control fields b) All customers control fields have the same format c) One control field is issued for all customers

Copyright © K.Goseva 2006 CS 230 Introduction to Software Engineering Slide 5

Characteristics of Good RD&S (Contd)

• Complete
  • Inclusion of all significant functional and non-functional requirements
  • Specification of the responses to valid and invalid input values
  • Conformity to any standard that applies
  • Full labeling and referencing of all figures, tables, and diagrams and definition of all terms and units of measure
  • Any RD&S that uses the phrase to be determined (TBD) is not complete

Copyright © K.Goseva 2006 CS 230 Introduction to Software Engineering Slide 6

Characteristics of Good RD&S (Contd)

• Verifiable
  • There exists some finite cost-effective process which a person or machine can check that the software product meets the requirements
  • Examples of non-verifiable requirements statements o The product should work well o The output of the program shall usually be given within 10 s

Copyright © K.Goseva 2006 CS 230 Introduction to Software Engineering Slide 7

Characteristics of Good RD&S (Contd)

• Consistent
  • No set of individual requirements conflicts
• Examples:
  • One requirement might state the format on the output report as tabular , but another as textual

Copyright © K.Goseva 2006 CS 230 Introduction to Software Engineering Slide 8

Characteristics of Good RD&S (Contd)

• Modifiable
  • Necessary changes to the requirements can be made easily, completely, and consistently
  • Coherent, easy-to-use organization – table of contents, an index, explicit cross-referencing
  • Not be redundant

Copyright © K.Goseva 2006 CS 230 Introduction to Software Engineering Slide 9

Characteristics of Good RD&S (Contd)

• Traceable
  • Backward traceability
  • Forward traceability
• Usable during the operation and maintenance

phase

Copyright © K.Goseva 2006 CS 230 Introduction to Software Engineering Slide 10

Requirement Analysis Principles

• Large number of analysis modeling methods
• Common set of operational principles
  • The information domain of a problem must be represented and understood
  • The functions must be defined
  • The behavior as a consequence of external events must be defined
  • The models that depict information, function, and behavior must be partitioned in a layered (or hierarchical) fashion
  • Analysis process should move from essential information towards implementation detail

Copyright © K.Goseva 2006 CS 230 Introduction to Software Engineering Slide 11

Information Domain

• Software processes data and events (represent

aspects of system control)

• Information flow represents the manner in which data and control change as they move through system
• Information structure represents internal organization of various data and control items

**Transform

Transform #**

Data/Control store

Input object(s)

Output object(s)

Intermediate data and control

Copyright © K.Goseva 2006 CS 230 Introduction to Software Engineering Slide 12

Modeling

• Functional models
  • Start from context model
  • Over a series of iteration add more information
• Behavioral models
  • Stimulus / response characteristics
• Models
  • help the analyst in understanding the information, function, and behavior of the system
  • Are important for determination of completeness, consistency and accuracy of specification
  • Provide basis for design
• Modeling is fundamental to good analysis work

Copyright © K.Goseva 2006 CS 230 Introduction to Software Engineering Slide 13

Partitioning

• Problems are usually too large and complex
  • Partition (divide, decompose) the problem into parts
  • Establish interfaces between parts
• Decompose the problem functionally by moving

horizontally in the hierarchy

• Expose increasing level of detail by moving

vertically in the hierarchy

Copyright © K.Goseva 2006 CS 230 Introduction to Software Engineering Slide 14

Example of partitioning

• SafeHome software enables the homeowner to

configure the system when it is installed, monitors

all sensors connected to the security system, and

interacts with the homeowner through a keypad

and function keys contained in the SafeHome

control panel

Copyright © K.Goseva 2006 CS 230 Introduction to Software Engineering Slide 15

Horizontal partitioning - functions

SafeHome software

Configure system Monitor sensors Interact with user

Copyright © K.Goseva 2006 CS 230 Introduction to Software Engineering Slide 16

Vertical (hierarchical) partitioning - details

SafeHome software

Configure system Monitor sensors Interact with user

Poll for sensor event

Activate alarm functions

Identify event type

Read sensor status

Activate / deactivate sensor

Activate audible alarm

Dial phone number

Copyright © K.Goseva 2006 CS 230 Introduction to Software Engineering Slide 17

Software Requirements Specification

• developed as a consequence of analysis
• review is essential to ensure that the developer

and the customer have the same perception of the

system

• even with the best of methods, the problem is that

the problem keeps changing

Copyright © K.Goseva 2006 CS 230 Introduction to Software Engineering Slide 18

Sample Formats

• Based on the IEEE Standard 830: Software

Requirements Specifications

• Requirements Definition
• Requirements Specification