ICS 52: Introduction to Software Engineering

1
ICS 52 Introduction to Software Engineering

• Lecture Notes for Summer Quarter, 2003
• Michele Rousseau
• Topic 4
• Partially based on lecture notes written by
  Sommerville, Richard N. Taylor, André van der
  Hoek, Dan Frost and Doris Tonne. Duplication of
  course material for any commercial purpose
  without the written permission of the lecturers
  is prohibited

2
Todays Lecture

• Requirements Engineering
• Components of a Requirements Document

3
Requirements engineering

• The process of establishing the services that
  the customer requires from a system and the
  constraints under which it operates and is
  developed sommerville
• What is a Requirement?
• It may range from a high-level abstract statement
  of a service or of a system constraint to a
  detailed mathematical functional specification

4
Requirements Engineering Processes

• Processes used to discover, analyse and validate
  system requirements

5
Requirements engineering processes

• The processes used for RE vary widely depending
  on the application domain, the people involved
  and the organisation developing the requirements
• However, there are a number of generic activities
  common to all processes
• Requirements elicitation
• Requirements analysis
• Requirements validation
• Requirements management

6
The Requirements Engineering Process
7
RE Process

• A feasibility study decides whether or not the
  proposed system is worthwhile
• Can it be done within the constraints?
• Elicitation and Analysis
• What is the application domain?
• What are the constraints
• Should involve all stakeholders
• End users, Managers, engineers
• Domain experts, unions etc..

8
Problems of requirements analysis

• Stakeholders dont 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

9
Requirements Specification

• Specify only external system behavior
• Specify constraints on implementation
• Easy to change
• Serve as a reference during maintenance
• Record forethought about system lifecycle
• Characterize responses to undesired events

10
Users of a Requirements Document
11
Structure

• Introduction
• Executive summary
• Application context
• Functional requirements
• Environmental requirements
• Software qualities

• Other requirements
• Time schedule
• Potential risks
• Future changes
• Acceptance Test Plan
• Glossary
• Reference documents

12
Introduction

• What is this document about?
• Who was it created for?
• Who created it?
• Outline

13
Executive Summary

• Short, succinct, concise, to-the-point,
  description
• Usually no more than one page
• Identifies main goals
• Identifies key features
• Identifies key risks/obstacles

14
Application Context

• Describes the situation in which the software
  will be used
• How will the situation change as a result of
  introducing the software?
• World Model
• Identifies all things that the system affects
• Objects, processes, other software, hardware, and
  people
• Provides an abstraction for each of those,
  characterizing the properties and behaviors that
  are relevant to the software system
• Identifies fundamental assumptions Likely
  Changes

15
Functional Requirements

• Describe functionality or system services
• Identifies all concepts, functions, features, and
  information that the system provides to its users
• Provides an abstraction for each of those,
  characterizing the properties and functions that
  are relevant to the user
• What is the system supposed to do?
• What information does the system need?
• What is supposed to happen when something goes
  wrong?

An approximate user interface is part of
functional requirements
16
Examples of Functional Requirements

• The user shall be able to search either all of
  the initial set of databases or select a subset
  from it.
• The system shall provide appropriate viewers for
  the user to read documents in the document store.
  
• Every order shall be allocated a unique
  identifier (ORDER_ID) which the user shall be
  able to copy to the accounts permanent storage
  area.

17
Requirements imprecision

• Problems arise when requirements are not
  precisely stated
• Ambiguous requirements may be interpreted in
  different ways by developers and users
• Consider the term appropriate viewers
• User intention - special purpose viewer for each
  different document type
• Developer interpretation - Provide a text viewer
  that shows the contents of the document

18
Non-functional requirements

• Define system properties and constraints e.g.
  reliability, response time and storage
  requirements. Constraints are I/O device
  capability, system representations, etc.
• Non-functional requirements may be more critical
  than functional requirements. If these are not
  met, the system is useless
• Environmental, performance, Qualities, and other
  Requirements

19
Non-Functional Requirement Types
20
Goals and requirements

• Non-functional requirements may be very difficult
  to state precisely and imprecise requirements may
  be difficult to verify.
• Goal
• A general intention of the user such as ease of
  use
• Verifiable non-functional requirement
• A statement using some measure that can be
  objectively tested
• Goals are helpful to developers as they convey
  the intentions of the system users

21
Examples

• A system goal
• The system should be easy to use by experienced
  controllers and should be organised in such a way
  that user errors are minimised.
• A verifiable non-functional requirement
• Experienced controllers shall be able to use all
  the system functions after a total of two hours
  training. After this training, the average number
  of errors made by experienced users shall not
  exceed two per day.

22
Requirements measures
23
Environmental Performance Requirements

• Environmental
• Platforms
• Operating Systems
• Hardware types of machines, memory size, hard
  disk space
• Software
• CORBA, Jini, DCOM, 4GL,
• Programming language(s)
• Performance
• Speed ( system response)

24
Software Qualities

• Correctness
• Reliability
• Robustness
• Performance
• User friendliness
• Verifiability
• Maintainability
• Repairability
• Safety

• Evolvability
• Reusability
• Portability
• Understandability
• Interoperability
• Productivity
• Size
• Timeliness
• Visibility

25
Other Requirements

• What about cost?
• What about documentation?
• What about manuals?
• What about tutorials?
• What about on-the-job training?
• What about requirements that do not fit in any of
  the previous categories?

26
Time Schedule

• By when should all of this be done?
• Initial delivery date
• Acceptance period
• Final delivery date
• What are some important milestones to be reached?
• Architectural design completed
• Module design completed
• Implementation completed
• Testing completed

27
Potential Risks

• Any project faces risks
• Boehms top ten risks (see Topic 2)
• It is important to identify those risks up-front
  so the customer and you (!) are aware of them
• One of the requirements could be to explicitly
  address the risks

28
Future Directions and Expected Changes (aka
Lifecycle Considerations)

• Any project faces changes over time
• Identify up front
• Awareness
• planning
• Future Enhancements
• One of the requirements could be to build the
  product such that it can accommodate future
  changes

29
Future Directions and Expected Changes (aka
Lifecycle Considerations)

• Serve as basis for future contracts, new versions
• Reduce future modification costs
• Identify items likely to change
• Identify fundamental assumptions
• Structure document to make future changes easy
• e.g. have a single location where all concepts
  are defined

30
Acceptance Test Plan

• Part of the requirements specification
• An operational way of determining consistency
  between the requirements specification and the
  delivered system
• If the system passes the tests demanded by this
  plan, then the buyer has no (legal, moral) basis
  for complaint
• Develop a plan for testing all aspects of the
  requirements specification
• e.g. Functional properties, performance,
  adherence to constraints

31
Glossary

• Precise definitions of terms used throughout the
  requirements document

32
Reference Documents

• Pointers to existing processes and tools used
  within an organization
• Pointers to other, existing software that provide
  similar functionality
• Pointers to literature

33
Observations

• Document is structured to address the fundamental
  principles
• Rigor
• Separation of concerns
• Modularity
• Abstraction
• Anticipation of change
• Generality
• Incrementality
• Not every section of the document is relevant to
  every project, but this should be stated.

34
Requirements requirements

• Specify only external system behavior
• Specify constraints on implementation
• Easy to change
• Serve as a reference during maintenance
• Record forethought about system lifecycle
• Characterize responses to undesired events

35
Why spend a lot of time?
One of the best-known folk theorems of software
engineering is that 60 to 75 of
conventional software projects are either never
completed or rejected by their intended users.
If that range is anywhere near true (and Ive
never met a manager of any experience who
disputes it) then more projects than not are
being aimed at goals which are either (a) not
realistically attainable, or (b) just plain
wrong. -- Eric S. Raymond, The Cathedral and The
Bazaar
36
Different Circumstances, Different Techniques

• Natural language Structured Natural Language
• Data flow diagrams
• Office automation
• Finite state machines
• Telephone systems
• Coin-operated machines
• Scenarios and Use Case Diagrams
• Petri nets
• Production plants
• Formulas
• Matrix inversion package

37
Problems with Natural Language

• Lack of clarity
• Precision is difficult without making the
  document difficult to read
• Requirements confusion
• Functional and non-functional requirements tend
  to be mixed-up
• Requirements amalgamation
• Several different requirements may be expressed
  together

38
Helpful Techniques

• Functional approach
• List of features
• Input and output pairs
• Potentially a shopping list or Recipe
• World model approach
• List of objects (object oriented)
• Place the system in context
• Ingredients and their possible uses

Both lead to a shopping list and dinner
39
Techniques for Requirements Analysis (review)

• Conduct interviews
• Build and evaluate prototypes
• Observe Customer
• Identify important objects/Roles/Functions
• Perform Research
• Construct glossaries
• Use precise notation (be careful with diagrams!)
• Question Yourself

Focus on the principles Separation of Concerns
Abstraction, modularity.. etc...
40
Completeness Consistency

• In principle requirements should be both complete
  and consistent
• Complete
• They should include descriptions of all
  facilities required
• Consistent
• There should be no conflicts or contradictions in
  the descriptions of the system facilities
• In practice, it is impossible to produce a
  complete and consistent requirements document

41
Conflicts/Consistency

• Conflicts between different non-functional
  requirements are common in complex systems
• Spacecraft system
• To minimise weight, the number of separate chips
  in the system should be minimised
• To minimise power consumption, lower power chips
  should be used
• However, using low power chips may mean that more
  chips have to be used. Which is the most critical
  requirement?

42
Questioning yourself

• Is the requirements specification
• complete?
• understandable?
• unambiguous
• consistent? (are there any conflicts?)
• verifiable? Testable?
• unbiased?
• Can each of the requirements be verified?
• Are are all terms and concepts defined?

43
Guidelines for writing requirements

• Use the standard format provided 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

44
Some Key points

• Requirements set out what the system should do
  and define constraints on its operation and
  implementation
• Functional requirements set out services the
  system should provide
• Non-functional requirements constrain the system
  being developed or the development process

45
How Can We Verify Requirements?

• Requirements reviews
• Systematic manual analysis of the requirements
• Prototyping
• Using an executable model of the system to check
  requirements. Covered in Chapter 8
• Test-case generation
• Developing tests for requirements to check
  testability
• Automated consistency analysis
• Checking the consistency of a structured
  requirements description

46
Your Tasks

• Read and study slides of this lecture
• Read Chapters 6, 7, and 9 of Sommerville
• Be familiar with system models
• Be familiar with formal models