TSE2451

TSE2451
Software Requirements Engineering

Test 1 Revision Note
Table of Contents
Description
Lecture 01
An Introduction to Requirements Engineering
Tutorial 01
Lecture 02
Requirements Engineering Processes
Tutorial 02
Lecture 03
Requirements Elicitation and Analysis
Tutorial 03
Past Year Examination Questions
Page
1
8
9
18
20
30
32
TSE2451
Software Requirements Engineering Test 1 Revision Note
Lecture 01: An Introduction to Requirements Engineering

Objectives
To introduce the notion of system requirements and the requirements engineering process.
To explain how requirements engineering fits into a broader system engineering process
To explain the importance of the requirements document
1. System requirements
Define what the system is required to do and the constraints under which it is required to
operate
The system shall maintain records of all library materials including books, serials,
newspapers and magazines, video and audio tapes, reports, collections of
transparencies, computer disks and CD-ROMs.
The system shall allow users to search for an item by title, author, or by ISBN.
The systems user interface shall be implemented using a World-Wide-Web browser.
The system shall support at least 20 transactions per second.
The system facilities which are available to public users shall be demonstrable in 10
minutes or less.
2. Types of requirements
Very general requirements which set out in broad terms what the system should do.
Functional requirements which define part of the systems functionality.
Implementation requirements which state how the system must be implemented.
Performance requirements which specify a minimum acceptable performance for the
system.
Usability requirements which specify the maximum acceptable time to demonstrate the
use of the system.
3. Requirements problems
The requirements dont reflect the real needs of the customer for the system.
Requirements are inconsistent and/or incomplete.
It is expensive to make changes to requirements after they have been agreed.
There are misunderstandings between customers, those developing the system
requirements and software engineers developing or maintaining the system.
Lecture 01
TSE2451
4. Frequently Asked Questions about requirements

(i) What are requirements?
A statement of a system service or constraint
(ii) What is requirements engineering?
The processes involved in developing system requirements
(iii)
How much does requirements engineering cost?
About 15% of system development costs
(iv)What is a requirements engineering process?
The structured set of activities involved in developing system requirements
(v) What happens when the requirements are wrong?
Systems are late, unreliable and dont meet customers needs
(vi)Is there an ideal requirements engineering process?
No processes must be tailored to organizational needs
(vii)
What is a requirements document?
The formal statement of the system requirements
(viii)
What are system stakeholders?
Anyone affected in some way by the system
(ix)What is the relationship between requirements and design?
Requirements and design are interleaved. They should, ideally, be separate
processes but in practice this is impossible
(x) What is requirements management?
The processes involved in managing changes to requirements
5. Systems engineering
There is a close relationship between software and more general system requirements
Computer-based systems fall into two broad categories:
User-configured systems where a purchaser puts together a system from existing
software products
Custom systems where a customer produces a set of requirements for
hardware/software system and a contractor develops and delivers that system
6. Classes of custom systems
Information systems
Primarily concerned with processing information which is held in some database.
Embedded systems
Systems where software is used as a controller in some broader hardware system
Command and control systems
Essentially, a combination of information systems and embedded systems where
special purpose computers provide information which is collected and stored and
used to make decisions
Lecture 01
TSE2451
7. Emergent properties
Emergent properties are properties of the system as a whole and only emerge once al of
its individual sub-systems have been integrated
Examples of emergent properties
Reliability
Maintainability
Performance
Usability
Security
Safety
8. The systems engineering process
9. The systems engineering activities

System requirements engineering
The requirements for the system as a whole are established and written to be
understandable to all stakeholders
Architectural design
The system is decomposed into sub-systems
Requirements partitioning
Requirements are allocated to these sub-systems
Software requirements engineering
More detailed system requirements are derived for the system software
Sub-system development
The hardware and software sub-systems are designed and implemented in parallel.
System integration
The hardware and software sub-systems are put together to make up the system.
System validation
The system is validated against its requirements.
Lecture 01
TSE2451
10. Requirements document

The requirements document is a formal document used to communicate the requirements
to customers, engineers and managers.
The requirements document describes:
The services and functions which the system should provide
The constraints under which the system must operate
Overall properties of the system i.e.. constraints on the systems emergent properties
Definitions of other systems which the system must integrate with.
Information about the application domain of the system e.g. how to carry out
particular types of computation
Constraints on the processes used to develop the system
Description of the hardware on which the system is to run
In addition, the requirements document should always include an introductory chapter
which provides an overview of the system, business needs supported by the system and a
glossary which explains the terminology used.
11. Users of requirements documents
System customers
Specify the requirements and read them to check they meet their needs
Project managers
Use the requirements document to plan a bid for system and to plan the system
development process
System engineers
Use the requirements to understand the system being developed
System test engineers
Use the requirements to develop validation tests for the system
System maintenance engineers
Use the requirements to help understand the system
Lecture 01
TSE2451
12. Requirements document structure

IEEE/ANSI 830-1993 standard proposes a structure for software requirements documents
1. Introduction
1.1 Purpose of requirements document
1.2 Scope of the product
1.3 Definitions, acronyms and abbreviations
1.4 References
1.5 Overview of the remainder of the document
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
Covering functional, non-functional and interface requirements.
4. Appendices
Index
13. Adapting the standard
The IEEE standard is a generic standard which is intended apply to a wide range of
requirements documents.
In general, not all parts of the standard are required for all requirements documents
Each organization should adapt the standard depending on the type of systems it develops
Consider a company (XYZ) that develops scientific instruments
14. Organization XYZ standard
Preface
This should define the expected readership of the document and describe its version
history including a rationale for the creation of a new version and a summary of the
changes made in each version.
Introduction
This should define the product in which the software is embedded, its expected usage
and present and overview of the functionality of the control software.
Glossary
This should define all technical terms and abbreviations used in the document.
General user requirements
This should define the system requirements from the perspective of the user of the
system. These should be presented using a mixture of natural language and diagrams.
System architecture
Lecture 01
TSE2451
This chapter should present a high-level overview of the anticipated system

architecture showing the distribution of functions across system modules.
Architectural components which are to be reused should be highlighted.
Hardware specification
This is an optional chapter specifying the hardware that the software is expected to
control. It may be omitted if the standard instrument platform is used.
Detailed software specification
This is a detailed description of the functionality expected of the software of the
system. It may include details of specific algorithms which should be used for
computation. If a prototyping approach is to be used for development on the standard
instrument platform, this chapter may be omitted.
Reliability and performance requirements
This chapter should describe the reliability and performance requirements which are
expected of the system. These should be related to the statement of user requirements
in Chapter 4.
The following appendices may be included where appropriate:
Hardware interface specification
Software components which must be reused in the system implementation
Data structure specification
Data-flow models of the software system
Detailed object models of the software system
Index
15. Writing requirements

Requirements are usually written as paragraphs of natural language text supplemented by
diagrams and equations
Problems with requirements
Use of complex conditional clauses which are confusing
Sloppy and inconsistent terminology
Writers assume readers have domain knowledge
16. Writing essentials
Requirements are read more often than they are written. You should invest time to write
readable and understandable requirements
Do not assume that all readers of the requirements have the same background and use the
same terminology as you
Allow time for review, revision and re-drafting of the requirements document
17. Writing guidelines
Define standard templates for describing requirements
Use language simply consistently and concisely
Use diagrams appropriately
Supplement natural language with other description of requirements
6
Lecture 01
TSE2451
Specify requirements quantitatively
Key Points
1. Requirements define what the system should provide and define system constraints
2. Requirements problems lead to late delivery and change requests after the system is in use
3. Requirements engineering is concerned with eliciting, analysing, and documenting the
system requirements
4. Systems engineering is concerned with systems as a whole including hardware, software and
operational processes
5. The requirements document is the definitive specification of requirements for customers,
engineers and managers.
6. The requirements document should include a system overview, glossary, statement of the
functional requirements and the operational constraints
Lecture 01
TSE2451
Tutorial 01: An Introduction to Requirements Engineering

1. List the possible stakeholders for a library cataloguing system.
Library Users
Cataloging Staff
Library Management
Helpdesk
Book Publishers (indirect)
Systems Developers
Managers of other library automation systems
2. Suggest the uses which each of the stakeholders which you have identified in question 1
might make of a requirements document for a library system.
Library Users Not used directly but used to produce user documentation.
Library Staff Responsible for cataloguing Used to assess if the facilities specified are
those required to support the cataloguing process.
Library Management Used to asses if the system supports the overall goals of the
library.
Library Staff responsible for providing user assistance Used to assess whether or not
the retrieval facilities are those commonly used by end-users.
Book Publishers (indirect) No direct use of document.
Managers of other library automation system Used to check interactions with these
systems.
3. Suggest how the following requirements might be rewritten in a quantitative way. You may
use any metrics you like to express the requirements.
The library system shall be easy-to-use.

It should be possible to train end-users of the system to use all retrieval facilities in a
single 15 minute training session.
The library system shall provide reliable service to all classes of user.
The rate of occurrence of failures in the retrieval facilities of the system shall be to
less than 1 in 1000 queries.
The rate of occurrence of failure for the cataloging facilities of the system shall be
less than 1 in 500 cataloging operations.
The library system shall provide a rapid response to all user requests for book
information.
The average system response time for user requests shall be less that 4 seconds.
Tutorial 01
TSE2451
Lecture 02: Requirements Engineering Processes

Objectives
To introduce the notion of processes and process models for requirements engineering
To explain the critical role of people in requirements engineering processes
To explain why process improvements is important and to suggest a process improvement
model for requirements engineering
1. Processes
A process is an organized set of activities which transforms inputs to outputs
Process descriptions encapsulate knowledge and allow it to be reused
Examples of process descriptions
Instruction manual for a dishwasher
Cookery book
Procedures manual for a bank
Quality manual for software development
2. Design processes
Processes which involve creativity, interactions between a wide range of different people,
engineering judgment and background knowledge and experience
Examples of design processes
Writing a book
Organizing a conference
Designing a processor chip
Requirements engineering
3. Requirements Engineering process Inputs and Outputs
Lecture 02
TSE2451
4. Input / Output Description

Input or Output
Type
Existing system
Input
information
Stakeholder needs Input
Organizational
standards
Regulations
Input
Domain
information
Agreed
requirements
Input
System
specification
System models
Output
Input
Output
Output
Description
Information about the functionality of systems to be
replaced or other systems which interact with the system
being specified
Descriptions of what system stakeholders need from the
system to support their work
Standards used in an organization regarding system
development practice, quality management, etc.
External regulations such as health and safety regulations
which apply to the system.
General information about the application domain of the
system
A description of the system requirements which is
understandable by stakeholders and which has been agreed
by them
This is a more detailed specification of the system
functionality which may be produced in some cases
A set of models such as a data-flow model, an object
model, a process model, etc. which describes the system
from different perspectives.
5. Requirements Engineering process variability

Requirements Engineering processes vary radically from one organization to another
Factors contributing to this variability include
Technical maturity
Disciplinary involvement
Organizational culture
Application domain
There is therefore no ideal requirements engineering process
6. Process models
A process model is a simplified description of a process presented from a particular
perspective
Types of process model include:
Coarse-grain activity models
Fine-grain activity models
Role-action models
Entity-relation models
10
Lecture 02
TSE2451
7. Coarse-grain activity model of Requirements Engineering
8. Requirements Engineering process activities

Requirements elicitation
Requirements discovered through consultation with stakeholders
Requirements analysis and negotiation
Requirements are analyzed and conflicts resolved through negotiation
Requirements documentation
A requirements document is produced
Requirements validation
The requirements document is checked for consistency and completeness
9. Waterfall model of the software process
10. Context of the Requirements Engineering process
Lecture 02
11
TSE2451
11. Spiral model of the Requirements Engineering process
12. Actors in the Requirements Engineering process

Actors in a process are the people involved in the execution of that process
Actors are normally identified by their roles rather than individually
Requirements engineering involves actors who are primarily interested in the problem to
be solved (end-users, etc.) as well actors interested in the solution (system designers, etc.)
Role-action diagrams document which actors are involved in different activities
13. Rapid Application Development (RAD) for software prototyping
14. Role descriptions

Role
Domain expert
System end-user
Requirements engineer
Software engineer
Project manager
12
Description
Responsible for providing information about the application
domain and the specific problem in that domain which is to be
solved
Responsible for using the system after delivery
Responsible for eliciting and specifying the system
requirements
Responsible for developing the prototype software system
Responsible for planning and estimating the prototyping
project
Lecture 02
TSE2451
15. Human and social factors

Requirements engineering processes are dominated by human, social and organisational
factors because they always involve a range of stakeholders from different backgrounds
and with different individual and organizational goals.
System stakeholders may come from a range of technical and non-technical background
and from different disciplines
16. Types of stakeholder
Software engineers responsible for system development
System end-users who will use the system after it has been delivered
Managers of system end-users who are responsible for their work
External regulators who check that the system meets its legal requirements
Domain experts who give essential background information about the system application
domain
17. Factors influencing requirements
Personality and status of stakeholders
The personal goals of individuals within an organization
The degree of political influence of stakeholders within an organization
18. Process support
CASE tools provide automated support for software engineering processes
The most mature CASE tools support well-understood activities such as programming
and testing and the use of structured methods
Support for requirements engineering is still limited because of the informality and the
variability of the process
19. CASE tools for Requirements Engineering
Modeling and validation tools support the development of system models which can be
used to specify the system and the checking of these models for completeness and
consistency. The tool package which supports this book includes this type of tool.
Management tools help manage a database of requirements and support the management
of changes to these requirements.
Lecture 02
13
TSE2451
20. A Requirements Management System
21. Requirements Management Tools

Requirements browser
Requirements query system
Traceability support system
Report generator
Requirements converter and word processor linker
Change control system
22. Process improvement
Process improvement is concerned with modifying processes in order to meet some
improvement objectives
Improvement objectives
Quality improvement
Schedule reduction
Resource reduction
23. Planning process improvement
What are the problems with current processes?
What are the improvement goals?
How can process improvement be introduced to achieve these goals?
How should process improvements be controlled and managed?
24. Requirements Engineering process problems
Lack of stakeholder involvement
Business needs not considered
Lack of requirements management
14
Lecture 02
TSE2451
Lack of defined responsibilities

Stakeholder communication problems
Over-long schedules and poor quality requirements documents
25. Process maturity

Process maturity can be thought of as the extent that an organization has defined its
processes, actively controls these processes and provides systematic human and
computer-based support for them.
The Software Engineering Institutes (SEI) Capability Maturity Model is a framework for
assessing software process maturity in development organizations
26. Capability maturity model
27. Maturity levels

Initial level
Organizations have an undisciplined process and it is left to individuals how to
manage the process and which development techniques to use.
Repeatable level
Organizations have basic cost and schedule management procedures in place. They
are likely to be able to make consistent budget and schedule predictions for projects
in the same application area.
Defined level
The software process for both management and engineering activities is documented,
standardized and integrated into a standard software process for the organization.
Managed level
Detailed measurements of both process and product quality are collected and used to
control the process.
Optimizing level
The organization has a continuous process improvement strategy, based on objective
measurements, in place.
Lecture 02
15
TSE2451
28. Requirements Engineering process maturity model
29. Requirements Engineering process maturity levels

Initial level
No defined Requirements Engineering process. Suffer from requirements problems
such as requirements volatility, unsatisfied stakeholders and high rework costs.
Dependent on individual skills and experience.
Repeatable level
Defined standards for requirements documents and policies and procedures for
requirements management.
Defined level
Defined Requirements Engineering process based on good practices and techniques.
Active process improvement process in place.
30. Good practice for Requirements Engineering process improvement
Requirements Engineering processes can be improved by the systematic introduction of
good requirements engineering practice
Each improvement cycle identifies good practice guidelines and works to introduce them
in an organization
Examples of good practice guidelines
Define a standard document structure
Uniquely identify each requirement
Define policies for requirements management
Use checklists for requirements analysis
Use scenarios to elicit requirements
Specify requirements quantitatively
Use prototyping to animate requirements
Reuse requirements
16
Lecture 02
TSE2451
Key Points
1. The requirements engineering process is a structured set of activities which lead to the
production of a requirements document.
2. Inputs to the requirements engineering process are information about existing systems,
stakeholder needs, organizational standards, regulations and domain information.
3. Requirements engineering processes vary radically from one organization to another. Most
processes include requirements elicitation, requirements analysis and negotiation and
requirements validation.
4. Requirements engineering process models are simplified process description which are
presented from a particular perspective.
5. Human, social and organizational factors are important influences on requirements
engineering processes.
6. Requirements engineering process improvement is difficult and is best tackled in an
incremental way.
7. Requirements engineering processes can be classified according to their degree of maturity.
Lecture 02
17
TSE2451
Tutorial 02: Requirements Engineering Processes

1. Explain why there is a great deal of variability in the requirements engineering processes
used in different organizations.
There is a great deal of variability in the requirements engineering processes used in different
organizations because different organizations have different requirements engineering
processes as they are affected by the technical maturity, disciplinary involvement,
organization culture and application domain of the organization itself.
2. Define an activity model of the processes of checking a book out of a library, making an
omelette and installing some new software on your computer (this can be very challenging!).
You should choose an appropriate level of granularity for the models.
Checking out a library book:
Take book to counter

Show ID to librarian
Librarian validates
Librarian
bookissues
and IDreceipt with
Take
due
book
dateand leave
Making an omelette:
List the steps/find recipe and ingredients needed
Prepare the ingredients/tools and draft the expectation of the omelette (taste, look, shape, etc)
Follow the listed steps or recipe
Try the taste of the omelette
Omele
18
Tutorial 02
TSE2451
Installing new software:
Output:
Step 7: Software installed and work as expected.
Step 8: Test software by Giving input process
output.
3. Explain why the waterfall model of the software process is not an accurate reflection of the
detailed software processes in most organizations. Why is a spiral model more realistic?
The waterfall model is not an accurate reflection because it does not allow for mistakes and
the redo-ing of each activity. Most organizations have to go back to the previous activity to
undo a mistake several times when developing software. A spiral model would be more
realistic because all activities can be re-iterated several times.
Tutorial 02
19
TSE2451
Lecture 03: Requirements Elicitation and Analysis

Objectives
To describe the processes of requirements elicitation and analysis.
To introduce a number of requirements elicitation and requirements analysis techniques.
To discuss how prototypes may be used in the RE process.
1. Components of requirements elicitation
2. Elicitation activities
Application domain understanding
Application domain knowledge is knowledge of the general area where the system is
applied.
Problem understanding
The details of the specific customer problem where the system will be applied must
be understood.
Business understanding
You must understand how systems interact and contribute to overall business goals.
Understanding the needs and constraints of system stakeholders
You must understand, in detail, the specific needs of people who require system
support in their work.
20
Lecture 03
TSE2451
3. Elicitation, analysis and negotiation
4. The requirements elicitation process
5. Elicitation stages
Objective setting
The organizational objectives should be established including general goals of the
business, an outline description of the problem to be solved, why the system is
necessary and the constraints on the system.
Background knowledge acquisition
Background information about the system includes information about the
organization where the system is to be installed, the application domain of the system
and information about existing systems
Knowledge organization
The large amount of knowledge which has been collected in the previous stage must
be organized and collated.
Stakeholder requirements collection
System stakeholders are consulted to discover their requirements.
Lecture 03
21
TSE2451
6. Requirements analysis and negotiation
7. Analysis checks
Necessity checking
The need for the requirement is analysed. In some cases, requirements may be
proposed which dont contribute to the business goals of the organisation or to the
specific problem to be addressed by the system.
Consistency and completeness checking
The requirements are cross-checked for consistency and completeness. Consistency
means that no requirements should be contradictory; completeness means that no
services or constraints which are needed have been missed out.
Feasibility checking
The requirements are checked to ensure that they are feasible in the context of the
budget and schedule available for the system development.
8. Requirements negotiation
Requirements discussion
Requirements which have been highlighted as problematical are discussed and the
stakeholders involved present their views about the requirements.
Requirements prioritization
Disputed requirements are prioritized to identify critical requirements and to help the
decision making process.
Requirements agreement
Solutions to the requirements problems are identified and a compromise set of
requirements are agreed. Generally, this will involve making changes to some of the
requirements.
22
Lecture 03
TSE2451
9. Elicitation techniques
Specific techniques which may be used to collect knowledge about system requirements
This knowledge must be structured
Partitioning - aggregating related knowledge
Abstraction - recognising generalities
Projection - organising according to perspective
Elicitation problems
Not enough time for elicitation
Inadequate preparation by engineers
Stakeholders are unconvinced of the need for a new system
10. Special elicitation techniques
Interviews
Scenarios
Soft systems methods
Observations and social analysis
Requirements reuse
11. Interviews
The requirements engineer or analyst discusses the system with different stakeholders and
builds up an understanding of their requirements.
Types of interview
Closed interviews. The requirements engineer looks for answers to a pre-defined set
of questions
Open interviews. There is no predefined agenda and the requirements engineer
discusses, in an open-ended way, what stakeholders want from the system.
Interviewing essentials
Interviewers must be open-minded and should not approach the interview with preconceived notions about what is required
Stakeholders must be given a starting point for discussion. This can be a question, a
requirements proposal or an existing system
Interviewers must be aware of organizational politics - many real requirements may
not be discussed because of their political implications
12. Scenarios
Scenarios are stories which explain how a system might be used. They should include
a description of the system state before entering the scenario
the normal flow of events in the scenario
exceptions to the normal flow of events
information about concurrent activities
a description of the system state at the end of the scenario
Scenarios are examples of interaction sessions which describe how a user interacts with a
system
Discovering scenarios exposes possible system interactions and reveals system facilities
which may be required
Lecture 03
23
TSE2451
13. Library Scenario Document Ordering

Log on to EDDIS system
Issue order document command
Enter reference number of the required document
Select a delivery option
Log out from EDDIS
This sequence of events can be illustrated in a diagram
14. Scenarios and Object-Oriented Development

Scenarios are an inherent part of some object-oriented development methods
The term use-case (i.e. a specific case of system usage) is sometimes used to refer to a
scenario
There are different views on the relationship between use-cases and scenarios:
A use-case is a scenario
A scenario is a collection of use-cases. Therefore, each exceptional interaction is
represented as a separate use-case
15. Soft Systems Methods
These produce informal models of a socio-technical system. They consider the system,
the people and the organization
Not techniques for detailed requirements elicitation. Rather, they are ways of
understanding a problem and its organizational context
Software Systems Methodology (SSM) is probably the best known of these methods
The essence of SSM is its recognition that systems are embedded in a wider human and
organizational context
Stages of Software Systems Methodology (SSM)
Problem situation assessment
Problem situation description
Abstract system definition from selected viewpoints
Conceptual system modeling
Model/real-world comparison
Change identification
Recommendations for action
24
Lecture 03
TSE2451
16. Observation and social analysis

People often find it hard to describe what they do because it is so natural to them.
Sometimes, the best way to understand it is to observe them at work
Ethnography is a technique from the social sciences which has proved to be valuable in
understanding actual work processes
Actual work processes often differ from formal, prescribed processes
An ethnographer spends some time observing people at work and building up a picture of
how work is done
17. Ethnography guidelines
Assume that people are good at doing their job and look for non-standard ways of
working
Spend time getting to know the people and establish a trust relationship
Keep detailed notes of all work practices. Analyze them and draw conclusions from them
Combine observation with open-ended interviewing
Organize regular de-briefing session where the ethnographer talks with people outside the
process
Combine ethnography with other elicitation techniques
18. Ethnography in elicitation
19. Ethnographic perspectives

The work setting viewpoint
This describes the context and the physical location of the work and how people use
objects to carry out tasks. Therefore, in a study of a help desk (say), this would
describe the objects which the helper had to hand and how these were organized.
Social and organizational perspectives
This tries to bring out the day-to-day experience of work as seen by different people
who are involved. Each individual typically sees the work in a different ways and this
viewpoint tries to organize and integrate all of these perceptions.
The workflow viewpoint
Lecture 03
25
TSE2451
This viewpoint presents the work from a series of work activities with information
flowing from one activity to another.
20. Requirements reuse
Reuse involves taking the requirements which have been developed for one system and
using them in a different system
Requirements reuse saves time and effort as reused requirements have already been
analyzed and validated in other systems
Currently, requirements reuse is an informal process but more systematic reuse could lead
to larger cost savings
21. Reuse possibilities
Where the requirement is concerned with providing application domain information.
Where the requirement is concerned with the style of information presentation. Reuse
leads to a consistency of style across applications.
Where the requirement reflects company policies such as security policies.
22. Prototyping
A prototype is an initial version of a system which may be used for experimentation
Prototypes are valuable for requirements elicitation because users can experiment with
the system and point out its strengths and weaknesses. They have something concrete to
criticize
Rapid development of prototypes is essential so that they are available early in the
elicitation process
Prototyping benefits
The prototype allows users to experiment and discover what they really need to
support their work
Establishes feasibility and usefulness before high development costs are incurred
Essential for developing the look and feel of a user interface
Can be used for system testing and the development of documentation
Forces a detailed study of the requirements which reveals inconsistencies and
omissions
Types of prototyping
Throw-away prototyping
o intended to help elicit and develop the system requirements.
o The requirements which should be prototyped are those which cause most
difficulties to customers and which are the hardest to understand. Requirements
which are well-understood need not be implemented by the prototype.
Evolutionary prototyping
o intended to deliver a workable system quickly to the customer.
o Therefore, the requirements which should be supported by the initial versions of
this prototype are those which are well-understood and which can deliver useful
end-user functionality. It is only after extensive use that poorly understood
requirements should be implemented.
26
Lecture 03
TSE2451
Prototyping costs and problems

Training costs - prototype development may require the use of special purpose tools
Development costs - depend on the type of prototype being developed
Extended development schedules - developing a prototype may extend the schedule
although the prototyping time may be recovered because rework is avoided
Incompleteness - it may not be possible to prototype critical system requirements
Approaches to prototyping
Paper prototyping
o a paper mock-up of the system is developed and used for system experiments
Wizard of Oz prototyping
o a person simulates the responses of the system in response to some user inputs
Executable prototyping
o a fourth generation language or other rapid development environment is used to
develop an executable prototype
Executable prototype development
Fourth generation languages based around database systems
Visual programming languages such as Visual Basic or ObjectWorks
Internet-based prototyping solutions based on World Wide Web browsers and
languages such as Java
23. Requirements analysis

The goal of analysis is to discover problems, incompleteness and inconsistencies in the
elicited requirements. These are then fed back to the stakeholders to resolve them through
the negotiation process
Analysis is interleaved with elicitation as problems are discovered when the requirements
are elicited
A problem checklist may be used to support analysis. Each requirement may be assessed
against the checklist
Lecture 03
27
TSE2451
24. Analysis checklists

Premature design
Does the requirement include premature design or implementation information?
Combined requirements
Does the description of a requirement describe a single requirement or could it be
broken down into several different requirements?
Unnecessary requirements
Is the requirement gold plating? That is, is the requirement a cosmetic addition to
the system which is not really necessary.
Use of non-standard hardware
Does the requirement mean that non-standard hardware or software must be used? To
make this decision, you need to know the computer platform requirements.
Conformance with business goals
Is the requirement consistent with the business goals defined in the introduction to the
requirements document? Requirements ambiguity
Requirements ambiguity
Is the requirement ambiguous i.e. could it be read in different ways by different
people? What are the possible interpretations of the requirement?
Requirements realism
Is the requirement realistic given the technology which will be used to implement the
system?
Requirements testability
Is the requirement testable, that is, is it stated in such a way that test engineers can
derive a test which can show if the system meets that requirement?
25. Interaction matrices
26. Requirements negotiation

Disagreements about requirements are inevitable when a system has many stakeholders.
Conflicts are not failures but reflect different stakeholder needs and priorities
Requirements negotiation is the process of discussing requirements conflicts and reaching
a compromise that all stakeholders can agree to
In planning a requirements engineering process, it is important to leave enough time for
negotiation. Finding an acceptable compromise can be time-consuming
28
Lecture 03
TSE2451
27. Negotiation meetings

An information stage where the nature of the problems associated with a requirement is
explained.
A discussion stage where the stakeholders involved discuss how these problems might be
resolved.
All stakeholders with an interest in the requirement should be given the opportunity
to comment. Priorities may be assigned to requirements at this stage.
A resolution stage where actions concerning the requirement are agreed.
These actions might be to delete the requirement, to suggest specific modifications to
the requirement or to elicit further information about the requirement.
Key Points
1. Requirements elicitation involves understanding the application domain, the specific problem
to be solved, the organizational needs and constraints and the specific facilities needed by
system stakeholders.
2. The processes of requirements elicitation, analysis and negotiation are iterative, interleaved
processes which must usually be repeated several times.
3. There are various techniques of requirements elicitation which may be used including
interviewing, scenarios, soft systems methods, prototyping and participant observation.
4. Prototypes are effective for requirements elicitation because stakeholders have something
which they can experiment with to find their real requirements.
5. Checklists are particularly useful as a way of organizing the requirements validation process.
They remind analysts what to look for when reading through the proposed requirements.
6. Requirements negotiation is always necessary to resolve requirements conflicts and remove
requirements overlaps. Negotiation involves information interchange, discussion and
resolution of disagreements.
Lecture 03
29
TSE2451
Tutorial 03: Requirements Elicitation and Analysis

1. Using examples to support your answer, explain why domain knowledge is important in the
requirements elicitation process.
Domain knowledge is important in requirement elicitation because in order to elicit the
correct and complete requirements of the software, one will need to have general knowledge
of the field in which the software is being applied to. For instance, to build a banking system,
RE will need to understand how general banking works first and then proceed to
communicate with the clients.
2. Explain why a combination of ethnography and prototyping is useful for requirements
elicitation?
Requirement engineer able adopt the actual technical maturity of the organization. For
example there are organization that are not at all matured using the technology. Adopting to
their work culture and getting their need and develop something according to their need and
maturity is far more efficient process. These works together with prototyping which allows
users to experiment and discover what they really need to support their work. Essential for
developing the look and feel of a user interface. From there the developer able get more
information about the real need of the customer as the user providing continuous feedbacks
and comments.
3. Write plausible scenarios for the following activities:
o Registering for a university or college course
o Transferring funds from one account to another using an ATM
o Searching a library catalogue for books on the topic of requirements elicitation.
o Registering for a university or college course:
1) Login to subject registration website
2) Notification of successful login
3) Choose subject
4) Subject time slot is displayed
5) Choose a section of the subject
6) Confirm selection
7) System checks for time clashes and pre-requisites
8) If requirements match, System notifies of Successful Registration. Else, System
shows decline message.
9) Logout
30
Tutorial 03
TSE2451
o Transferring funds from one account to another using an ATM:

1) Enter card into machine
2) Enter PIN
3) Select transfer option
4) Identify balance of account
5) Identify destination account
6) Input amount to be transferred
7) Close transaction
8) Retrieve card
9) Print receipt
o Searching a library catalogue for books on the topic of requirements elicitation:
1) Log on to Library Management system.
2) User authentication successful login.
3) Enter topic in the Search box as requirements elicitation.
4) All outcome of query which related to the topic is posted.
5) Log out from system.
Tutorial 03
31
TSE2451

(Trimester 2, 2008/2009)
Question 1
(a) Many systems engineering problems stem from problems with the system requirements.
Identify THREE common requirements problems.
(3 marks)
(b) Suggest how the following requirements might be rewritten in a quantitative way. You may
use any metrics you like to express the requirements.
(i)
The library system shall be easy-to-use.
(ii)
The library system shall provide reliable service to all classes of user.
(iii)
The library system shall provide a rapid response to all user requests for book
information.
(3 marks)
(c) Explain at least THREE reasons why there is a great deal of variability in the requirements
engineering processes used in different organizations.
(3 marks)
(d) Define an activity model of the processes of installing some new software on your computer.
You should choose an appropriate level of granularity for the models.
(4 marks)
(e) Identify TWO characteristics of Requirements Specification.
(2 marks)
Question 2
(a) Using examples to support your answer, explain why domain knowledge is important in the
requirements elicitation process.
(3 marks)
(b) Identify possible stakeholders in the following system:
(4 marks)
An information system for television schedulers which provides information about viewing
figures for all programmes produced by different TV stations as well as other information
about major events, such as football matches, which may affect programme scheduling.
(c) What is the critical distinction between throw-away and evolutionary prototyping? (4 marks)
(d) In checks of object models of a system, give examples of two problems which can be
discovered automatically by CASE tools and two problems which can only he discovered by
manual inspection.
(4 marks)
32
TSE2451
(Trimester 1, 2010/2011)
Question 1
(a) Briefly describe the FOUR elicitation stages.
(4 marks)
(b) Mention two advantages and disadvantages of using formal methods in requirements
engineering?
(4 marks)
(c) Explain in details TWO types of traceability.
(4 marks)
(d) Writing a user manual from the requirements forces a detailed requirements analysis. What
is information is most crucial to be included in the user manual?
(3 marks)
Question 2
(a) List the possible stakeholders for a library cataloguing system.
(6 marks)
(b) What factors are likely to be particularly significant when considering requirements
engineering process improvement?
(4 marks)
(c) Draw a role-action diagram to show the actors association with the different RAD for
software prototyping process activities.
(5 marks)
(Trimester 2, 2010/2011)
Question 1
(a) Briefly describe FOUR consequences when the requirements are wrong.
(4 marks)
(b) Identify the possible stakeholders for a university management system.
(5 marks)
(c) What are the THREE types of traceability analysis? List down the processes supported for
each of the traceability analysis.
(6 marks)
33
TSE2451
(Trimester 1, 2011/2012)
Question 1
(a) Why is it sometimes necessary for requirements documents to include information about the
design of a system?
(4 marks)
(b) Identify the possible stakeholders for a hospital management system.
(5 marks)
(c) Systems integration is an important systems engineering activity. Suggest at least THREE
problems which might arise when subsystems from different suppliers are integrated.
(6
marks)
(Trimester 1, 2012/2013)
Question 2
(a) In the requirements interaction matrix below; 1 refers to conflict, 1000 refers to overlap, and
0 to independence.
(Total: 7 marks)
Requirement
R1
R2
R3
R4
R5
R6
R1
0
0
1000
0
1
1
R2
0
0
0
0
0
0
R3
1000
0
0
1000
0
1000
R4
0
0
1000
0
1
1
R5
1
0
0
1
0
0
R6
1
0
1000
1
0
0
(a1) Starting with the most-problematic and ending with the least-problematic, list down the
requirements R1, R2, R3, R4, R5, and R6 (explain the logic behind your answer).
(6
marks)
(a2)
What is the disadvantage of using the requirements interaction matrix?
(1 mark)
(b) Draw the role-action diagram to show the actors association with different RAD for
software prototyping process activities.
(5 marks)
(c) Differentiate between mutable, emergent and consequential requirements.
34
(3 marks)
TSE2451
(Trimester 1 Supplementary, 2012/2013)

Question 2
(a) The figure below depicts the procedure of pre-review checking. Name the components
labeled E, F, G, H and I.
(5 marks)
(b) A video library intends to develop an interactive web-based video-on-demand system for its
customers. The service will allow its members to select and play video recordings of their
choice via the Internet. Identify three potential direct and two indirect viewpoints of the
system and their likely concerns or requirements.
(5 marks)
(c) List six possible stakeholders for the Siti Hasmah Digital Library library system at
Multimedia University.
(3 marks)
(d) Why are system requirements hard-to-test?
(1 mark)
(e) Why is reliability considered a hard-to-test requirement?
(1 mark)
Question 4
(a) Write plausible scenarios for the following activities:
(a1)
Registering for a university or college course
(5 marks)
(a2)
Transferring funds from one account to another using an ATM
(5 marks)
(a3) Searching a library catalogue for books on the topic of requirements elicitation. If there
are no books with this title, you should extend your search to related areas.
(5 marks)
35
TSE2451
(Trimester 2, 2012/2013)
Question 2
(a) The figure below depicts the procedure of pre-review checking. Name the components
labeled E, F, G, H and I.
(5 marks)
(b) A video library intends to develop an interactive web-based video-on-demand system for its
customers. The service will allow its members to select and play video recordings of their
choice via the Internet. Identify three potential direct and two indirect viewpoints of the
system and their likely concerns or requirements.
(5 marks)
(c) List six possible stakeholders for the Siti Hasmah Digital Library library system at
Multimedia University.
(3 marks)
(d) Why are system requirements hard-to-test?
(1 mark)
(e) Why is reliability considered a hard-to-test requirement?
(1 mark)
36
TSE2451
Question 4
(a) A Library Scenario-document ordering can be summarized in the following sequence of
events:
Log on to Electronic Document Delivery Interchanging System (EDDIS)

Issue order document command
Enter reference number of the required document
Select a delivery option
Log out from EDDIS
Draw a diagram to represent the sequence of events along with possible respective
exceptions.
(5 marks)
(b) In the requirements interaction matrix below; 1 refers to conflict, 1000 refers to overlap, and
0 to independence.
(8 marks)
Requirement
R1
R2
R3
R4
R5
R6
R1
0
0
1000
0
1
1
R2
0
0
0
0
0
0
R3
1000
0
0
1000
0
1000
R4
0
0
1000
0
1
1
R5
1
0
0
1
0
0
R6
1
0
1000
1
0
0
Starting with the most-problematic and ending with the least-problematic, list down the
requirements R1, R2, R3, R4, R5, and R6 (explain the logic behind your answer).
(c) Differentiate between mutable and emergent and requirements.
(2 marks)
37

TSE2451 - Test 1 Revision Note

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

TSE2451 - Test 1 Revision Note

Încărcat de

Drepturi de autor:

Formate disponibile

Software Requirements Engineering

Software Requirements Engineering Test 1 Revision Note

Lecture 01: An Introduction to Requirements Engineering

An Introduction to Requirements Engineering

Software Requirements Engineering Test 1 Revision Note

4. Frequently Asked Questions about requirements

An Introduction to Requirements Engineering

Software Requirements Engineering Test 1 Revision Note

9. The systems engineering activities

An Introduction to Requirements Engineering

Software Requirements Engineering Test 1 Revision Note

10. Requirements document

An Introduction to Requirements Engineering

Software Requirements Engineering Test 1 Revision Note

12. Requirements document structure

An Introduction to Requirements Engineering

Software Requirements Engineering Test 1 Revision Note

This chapter should present a high-level overview of the anticipated system

15. Writing requirements

An Introduction to Requirements Engineering

Software Requirements Engineering Test 1 Revision Note

Specify requirements quantitatively

An Introduction to Requirements Engineering

Software Requirements Engineering Test 1 Revision Note

Tutorial 01: An Introduction to Requirements Engineering

The library system shall be easy-to-use.

An Introduction to Requirements Engineering

Software Requirements Engineering Test 1 Revision Note

Lecture 02: Requirements Engineering Processes

Requirements Engineering Processes

Software Requirements Engineering Test 1 Revision Note

4. Input / Output Description

5. Requirements Engineering process variability

Requirements Engineering Processes

Software Requirements Engineering Test 1 Revision Note

7. Coarse-grain activity model of Requirements Engineering

8. Requirements Engineering process activities

10. Context of the Requirements Engineering process

Requirements Engineering Processes

Software Requirements Engineering Test 1 Revision Note

11. Spiral model of the Requirements Engineering process

12. Actors in the Requirements Engineering process

14. Role descriptions

Requirements Engineering Processes

Software Requirements Engineering Test 1 Revision Note

15. Human and social factors

Requirements Engineering Processes

Software Requirements Engineering Test 1 Revision Note

20. A Requirements Management System

21. Requirements Management Tools

Requirements Engineering Processes

Software Requirements Engineering Test 1 Revision Note

Lack of defined responsibilities

25. Process maturity

27. Maturity levels

Requirements Engineering Processes

Software Requirements Engineering Test 1 Revision Note

28. Requirements Engineering process maturity model

29. Requirements Engineering process maturity levels

Requirements Engineering Processes

Software Requirements Engineering Test 1 Revision Note

Requirements Engineering Processes