You are on page 1of 162

Rekayasa Perangkat Lunak

(IF303) -Pertemuan 3 (System


Engineering)-
Tanti Kristanti, ST., MT.
tantikristanti02@yahoo.com
The Hierarchy
Business or
Product Domain
World view

Domain of interest

Domain view

System element

Element view

Detailed view
Business Process Engineering
 uses an integrated set of procedures,
methods, and tools to identify how
information systems can best meet the
strategic goals of an enterprise
 focuses first on the enterprise and then on
the business area
 creates enterprise models, data models and
process models
 creates a framework for better information
management distribution, and control
The BPE Hierarchy
• Information strategy planning (ISP)
strategic goals defined
success factors/business rules
identified
enterprise model created
• Business area analysis (BAA)
processes/services modeled
interrelationships of processes and
data
• Application Engineering
a.k.a ... software engineering
modeling applications/procedures that
address (BAA) and constraints of ISP
• Construction and delivery
using CASE and 4GTs, testing
Information Strategy Planning
• Management issues
define strategic business goals/objectives
isolate critical success factors
conduct analysis of technology impact
perform analysis of strategic systems
• Technical issues
create a top-level data model
cluster by business/organizational area
refine model and clustering
Defining Objectives and Goals
• Objective—general statement of
direction
• Goal—defines measurable objective:
“reduce manufactured cost of our
product”
Subgoals:
decrease reject rate by 20% in first 6
months
gain 10% price concessions from suppliers
re-engineer 30% of components for ease
of manufacture during first year
• objectives tend to be strategic while
goals tend to be tactical
Business Area Analysis
• define “naturally cohesive groupings of
business functions and data” (Martin)
• perform many of the same activities as
ISP, but narrow scope to individual
business area
• identify existing (old) information
systems / determine compatibility with
new ISP model
 define systems that are problematic
 defining systems that are incompatible with new
information model
 begin to establish re-engineering priorities
The BAA Process
admin.
manufacturing

QC distribution
sales
acct eng’ring

Process
Matrices
Process Decomp.
e.g.,
Flow Data Diagram
entity/process
Models Model
matrix
Product Engineering
The complete
System analysis
product
(World view)

capabilities

hardware software
Component
engineering
(Domain view)

Processing requirement

function behavior
Analysis & Design
data
Modeling
(Element view)

program
component Software
Engineering

Construction
&
Integration
(Detailed view)
Requirements Engineering
• Elicitation — determining what the customer
requires
• Analysis & negotiation — understanding the
relationships among various customer
requirements and shaping those relationships to
achieve a successful result
• Requirements specification — building a
tangible model of requirements
Requirements Engineering
• System Modeling — building a
representation of requirements that can
be assessed for correctness, completeness,
and consistency
• Validation — reviewing the model
• Management — identify, control and
track requirements and the changes that
will be made to them
Product Architecture Template

user interface processing

input process and control output


processing functions processing

maintenance and self-test


Architecture Flow Diagram
operator
interface operator requests CLSS queries, reports, displays
operator
interface
subsystem
bar code acquisition request
shunt control status
sorting reports

CLSS processing & control report timing/location data


requests

part shunt shunt


bar code bar code number control controller
reader decoding subsystem
subsystem subsystem

raw bar bin


code data shunt commands
location
bar code
data base
access
subsystem report CLSS reports
line
sensor data speed key formating
acquisition subsystem
subsystem sort records
mainframe
communications
BCR status driver
diagnostics shunt status
pulse tach input sensor status
subsystem formated
communications status reporting data
data acquisition bar code
interface reader status diagnostic interface output interface
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.
• The requirements themselves are the
descriptions of the system services and
constraints that are generated during the
requirements engineering process.
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.
• This is inevitable as requirements may serve
a dual function
– May be the basis for a bid for a contract -
therefore must be open to interpretation;
– May be the basis for the contract itself -
therefore must be defined in detail;
– Both these statements may be called
requirements.
Requirements abstraction (Davis)

“If a company wishes to let a contract for a large software development project, it
must define its needs in a sufficiently abstract way that a solution is not pre-defined.
The requirements must be written so that several contractors can bid for the contract,
offering, perhaps, different ways of meeting the client organisation’s needs. Once a
contract has been awarded, the contractor must write a system definition for the client
in more detail so that the client understands and can validate what the software will
do. Both of these documents may be called the requirements document for the
system.”
Types of requirement
• User requirements
– Statements in natural language plus diagrams
of the services the system provides and its
operational constraints. Written for customers.
• System requirements
– A structured document setting out detailed
descriptions of the system’s functions, services
and operational constraints. Defines what should
be implemented so may be part of a contract
between client and contractor.
Definitions and specifications
Requirements readers
Functional and non-functional requirements
• Functional requirements
– Statements of services the system should provide, how the
system should react to particular inputs and how the system
should behave in particular situations.
• Non-functional requirements
– constraints on the services or functions offered by the system
such as timing constraints, constraints on the development
process, standards, etc.
• Domain requirements
– Requirements that come from the application domain of the
system and that reflect characteristics of that domain.
Functional requirements
• Describe functionality or system services.
• Depend on the type of software, expected users
and the type of system where the software is
used.
• Functional user requirements may be high-level
statements of what the system should do but
functional system requirements should describe
the system services in detail.
The LIBSYS system
• A library system that provides a single
interface to a number of databases of
articles in different libraries.
• Users can search for, download and print
these articles for personal study.
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 account’s permanent
storage area.
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.
Requirements completeness and 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.
Non-functional requirements
• These define system properties and
constraints e.g. reliability, response time and
storage requirements. Constraints are I/O
device capability, system representations,
etc.
• Process requirements may also be specified
mandating a particular CASE system,
programming language or development
method.
• Non-functional requirements may be more
critical than functional requirements. If these
are not met, the system is useless.
Non-functional classifications
• Product requirements
– Requirements which specify that the delivered product must
behave in a particular way e.g. execution speed, reliability, etc.
• Organisational requirements
– Requirements which are a consequence of organisational
policies and procedures e.g. process standards used,
implementation requirements, etc.
• External requirements
– Requirements which arise from factors which are external to
the system and its development process e.g. interoperability
requirements, legislative requirements, etc.
Non-functional requirement types
Non-functional requirements
examples
• Product requirement
8.1 The user interface for LIBSYS shall be implemented as simple HTML
without frames or Java applets.
• Organisational requirement
9.3.2 The system development process and deliverable documents shall
conform to the process and deliverables defined in XYZCo-SP-STAN-
95.
• External requirement
7.6.5 The system shall not disclose any personal information about
customers apart from their name and reference number to the
operators of the system.
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.
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.
Requirements measures
Property Measure
Speed Processed transactions/second
User/Event response time
Screen refresh time
Size M Bytes
Number of ROM chips
Ease of use Training time
Number of help frames
Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robustness Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure
Portability Percentage of target dependent statements
Number of target systems
Requirements interaction
• 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?
Domain requirements
• Derived from the application domain
and describe system characteristics and
features that reflect the domain.
• Domain requirements be new functional
requirements, constraints on existing
requirements or define specific
computations.
• If domain requirements are not satisfied,
the system may be unworkable.
Library system domain
requirements
• There shall be a standard user interface
to all databases which shall be based on
the Z39.50 standard.
• Because of copyright restrictions, some
documents must be deleted immediately
on arrival. Depending on the user’s
requirements, these documents will either
be printed locally on the system server for
manually forwarding to the user or
routed to a network printer.
Train protection system

• The deceleration of the train shall be


computed as:
– Dtrain = Dcontrol + Dgradient
where Dgradient is 9.81ms2 * compensated
gradient/alpha and where the values of
9.81ms2 /alpha are known for different
types of train.
Domain requirements problems
• Understandability
– Requirements are expressed in the language
of the application domain;
– This is often not understood by software
engineers developing the system.
• Implicitness
– Domain specialists understand the area so
well that they do not think of making the
domain requirements explicit.
User requirements
• Should describe functional and non-
functional requirements in such a way
that they are understandable by system
users who don’t have detailed technical
knowledge.
• User requirements are defined using
natural language, tables and diagrams
as these can be understood by all users.
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.
LIBSYS requirement

4..5 LIBSYS shall provide a financial accounting


system that maintains records of all payments made
by users of the system. System managers may
configure this system so that regular users may
receive discounted rates.
Editor grid requirement

2.6 Grid facilities To assist in the positioning of entities on a diagram,


the user may turn on a grid in either centimetres or inches, via an
option on the control panel. Initially, the grid is off. The grid may be
turned on and off at any time during an editing session and can be
toggled between inches and centimetres at any time. A grid option
will be provided on the reduce-to-fit view but the number of grid
lines shown will be reduced to avoid filling the smaller diagram
with grid lines.
Requirement problems
• Database requirements includes both conceptual and
detailed information
– Describes the concept of a financial accounting system that is
to be included in LIBSYS;
– However, it also includes the detail that managers can
configure this system - this is unnecessary at this level.
• Grid requirement mixes three different kinds of
requirement
– Conceptual functional requirement (the need for a grid);
– Non-functional requirement (grid units);
– Non-functional UI requirement (grid switching).
Structured presentation

2.6.1 Grid facilities


The editor shall provide a grid facility where a matrix of horizontal and
vertical lines provide a background to the editor window. This grid shall be a
passive grid where the alignment of entities is the user's responsibility.
Rationale: A grid helps the user to create a tidy diagram with well-spaced
entities. Although an active grid, where entities 'snap-to' grid lines can be useful,
the positioning is imprecise. The user is the best person to decide where entities
should be positioned.
Specification: ECLIPSE/WS/Tools/DE/FS Section 5.6
Source: Ray Wilson, Glasgow Office
Guidelines for writing
requirements
• Invent a standard format and use it 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.
System requirements
• More detailed specifications of system
functions, services and constraints than
user requirements.
• They are intended to be a basis for
designing the system.
• They may be incorporated into the
system contract.
• System requirements may be defined or
illustrated using system models discussed
in Chapter 8.
Requirements and design
• In principle, requirements should state what
the system should do and the design should
describe how it does this.
• In practice, requirements and design are
inseparable
– A system architecture may be designed to
structure the requirements;
– The system may inter-operate with other
systems that generate design requirements;
– The use of a specific design may be a domain
requirement.
Problems with NL specification
• Ambiguity
– The readers and writers of the requirement
must interpret the same words in the same
way. NL is naturally ambiguous so this is
very difficult.
• Over-flexibility
– The same thing may be said in a number of
different ways in the specification.
• Lack of modularisation
– NL structures are inadequate to structure
system requirements.
Alternatives to NL specification

Notation Description
Structured natural This approach depends on defining standard forms or templates to express the
language requirements specification.
Design This approach uses a language like a programming language but with more abstract
description features to specify the requirements by defining an operational model of the system.
languages This approach is not now widely used although it can be useful for interface
specifications.
Graphical A graphical language, supplemented by text annotations is used to define the
notations functional requirements for the system. An early example of such a graphical
language was SADT. Now, use-case descriptions and sequence diagrams are
commonly used .
Mathematical These are notations based on mathematical concepts such as finite-state machines or
specifications sets. These unambiguous specifications reduce the arguments between customer and
contractor about system functionality. However, most customers don’t understand
formal specifications and are reluctant to accept it as a system contract.
Structured language specifications
• The freedom of the requirements writer is
limited by a predefined template for
requirements.
• All requirements are written in a standard
way.
• The terminology used in the description may
be limited.
• The advantage is that the most of the
expressiveness of natural language is
maintained but a degree of uniformity is
imposed on the specification.
Form-based specifications
• Definition of the function or entity.
• Description of inputs and where they
come from.
• Description of outputs and where they go
to.
• Indication of other entities required.
• Pre and post conditions (if appropriate).
• The side effects (if any) of the function.
Form-based node specification
Insulin Pump/Control Software/SRS/3.3.2
Function Compute insulin dose: Safe sugar level
Description Computes the dose of insulin to be delivered when the current measured sugar level is in
the safe zone between 3 and 7 units.
Inputs Current sugar reading (r2), the previous two readings (r0 and r1)
Source Current sugar reading from sensor. Other readings from memory.
OutputsCompDose Š the dose in insulin to be delivered
Destination Main control loop
Action: CompDose is zero if the sugar level is stable or falling or if the level is increasing but the rate of
increase is decreasing. If the level is increasing and the rate of increase is increasing, then CompDose is
computed by dividing the difference between the current sugar level and the previous level by 4 and
rounding the result. If the result, is rounded to zero then CompDose is set to the minimum dose that can
be delivered.
Requires Two previous readings so that the rate of change of sugar level can be computed.
Pre-condition The insulin reservoir contains at least the maximum allowed single dose of insulin..
Post-condition r0 is replaced by r1 then r1 is replaced by r2
Side-effects None
Tabular specification
• Used to supplement natural language.
• Particularly useful when you have to
define a number of possible alternative
courses of action.
Tabular specification

Condition Action
Sugar level falling (r2 < r1) CompDose = 0
Sugar level stable (r2 = r1) CompDose = 0
Sugar level increasing and rate of CompDose = 0
increase decreasing ((r2-r1)<(r1-r0))
Sugar level increasing and rate of CompDose = round ((r2-r1)/4)
increase stable or increasing. ((r2-r1) If rounded result = 0 then
(r1-r0)) CompDose = MinimumDose
Graphical models
• Graphical models are most useful when
you need to show how state changes or
where you need to describe a sequence of
actions.
Sequence diagrams
• These show the sequence of events that
take place during some user interaction
with a system.
• You read them from top to bottom to see
the order of the actions that take place.
• Cash withdrawal from an ATM
– Validate card;
– Handle request;
– Complete transaction.
Sequence diagram of ATM withdrawal
Interface specification
• Most systems must operate with other
systems and the operating interfaces
must be specified as part of the
requirements.
• Three types of interface may have to be
defined
– Procedural interfaces;
– Data structures that are exchanged;
– Data representations.
• Formal notations are an effective
technique for interface specification.
PDL interface description

interface PrintServer {

// defines an abstract printer server


// requires: interface Printer, interface PrintDoc
// provides: initialize, print, displayPrintQueue, cancelPrintJob, switchPrinter

void initialize ( Printer p ) ;


void print ( Printer p, PrintDoc d ) ;
void displayPrintQueue ( Printer p ) ;
void cancelPrintJob (Printer p, PrintDoc d) ;
void switchPrinter (Printer p1, Printer p2, PrintDoc d) ;
} //PrintServer
The requirements document
• The requirements document is the official
statement of what is required of the system
developers.
• Should include both a definition of user
requirements and a specification of the
system requirements.
• It is NOT a design document. As far as
possible, it should set of WHAT the system
should do rather than HOW it should do it
Users of a requirements document
IEEE requirements standard
• Defines a generic structure for a
requirements document that must be
instantiated for each specific system.
– Introduction.
– General description.
– Specific requirements.
– Appendices.
– Index.
Requirements document structure
• Preface
• Introduction
• Glossary
• User requirements definition
• System architecture
• System requirements specification
• System models
• System evolution
• Appendices
• Index
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.
The requirements engineering process
Requirements engineering
Feasibility studies
• A feasibility study decides whether or not
the proposed system is worthwhile.
• A short focused study that checks
– If the system contributes to organisational
objectives;
– If the system can be engineered using current
technology and within budget;
– If the system can be integrated with other
systems that are used.
Feasibility study
implementation
• Based on information assessment (what is required),
information collection and report writing.
• Questions for people in the organisation
– What if the system wasn’t implemented?
– What are current process problems?
– How will the proposed system help?
– What will be the integration problems?
– Is new technology needed? What skills?
– What facilities must be supported by the proposed system?
Elicitation and analysis
• Sometimes called requirements elicitation or
requirements discovery.
• Involves technical staff working with customers to find
out about the application domain, the services that the
system should provide and the system’s operational
constraints.
• May involve end-users, managers, engineers involved in
maintenance, domain experts, trade unions, etc. These
are called stakeholders.
Problems of requirements analysis
• Stakeholders don’t 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.
The requirements spiral
Process activities
• Requirements discovery
– Interacting with stakeholders to discover their requirements.
Domain requirements are also discovered at this stage.
• Requirements classification and organisation
– Groups related requirements and organises them into coherent
clusters.
• Prioritisation and negotiation
– Prioritising requirements and resolving requirements conflicts.
• Requirements documentation
– Requirements are documented and input into the next round
of the spiral.
Requirements discovery
• The process of gathering information
about the proposed and existing systems
and distilling the user and system
requirements from this information.
• Sources of information include
documentation, system stakeholders and
the specifications of similar systems.
ATM stakeholders
• Bank customers
• Representatives of other banks
• Bank managers
• Counter staff
• Database administrators
• Security managers
• Marketing department
• Hardware and software maintenance engineers
• Banking regulators
Viewpoints
• Viewpoints are a way of structuring the
requirements to represent the
perspectives of different stakeholders.
Stakeholders may be classified under
different viewpoints.
• This multi-perspective analysis is
important as there is no single correct
way to analyse system requirements.
Types of viewpoint
• Interactor viewpoints
– People or other systems that interact directly with the system.
In an ATM, the customer’s and the account database are
interactor VPs.
• Indirect viewpoints
– Stakeholders who do not use the system themselves but who
influence the requirements. In an ATM, management and
security staff are indirect viewpoints.
• Domain viewpoints
– Domain characteristics and constraints that influence the
requirements. In an ATM, an example would be standards for
inter-bank communications.
Viewpoint identification
• Identify viewpoints using
– Providers and receivers of system services;
– Systems that interact directly with the system
being specified;
– Regulations and standards;
– Sources of business and non-functional
requirements.
– Engineers who have to develop and
maintain the system;
– Marketing and other business viewpoints.
LIBSYS viewpoint hierarchy
Interviewing
• In formal or informal interviewing, the RE
team puts questions to stakeholders
about the system that they use and the
system to be developed.
• There are two types of interview
– Closed interviews where a pre-defined set of
questions are answered.
– Open interviews where there is no pre-
defined agenda and a range of issues are
explored with stakeholders.
Interviews in practice
• Normally a mix of closed and open-ended interviewing.
• Interviews are good for getting an overall
understanding of what stakeholders do and how they
might interact with the system.
• Interviews are not good for understanding domain
requirements
– Requirements engineers cannot understand specific domain
terminology;
– Some domain knowledge is so familiar that people find it hard
to articulate or think that it isn’t worth articulating.
Effective interviewers
• Interviewers should be open-minded,
willing to listen to stakeholders and
should not have pre-conceived ideas
about the requirements.
• They should prompt the interviewee with
a question or a proposal and should not
simply expect them to respond to a
question such as ‘what do you want’.
Scenarios
• Scenarios are real-life examples of how a
system can be used.
• They should include
– A description of the starting situation;
– A description of the normal flow of events;
– A description of what can go wrong;
– Information about other concurrent
activities;
– A description of the state when the scenario
finishes.
LIBSYS scenario (1)

Initial assumption: The user has logged on to the LIBSYS system and has located the journal containing
the copy of the article.
Normal: The user selects the article to be copied. He or she is then prompted by the system to ei ther
provide subscriber information for the journal or to indicate how they will pay for the article. Alternative
payment methods are by credit card or by quoting an organisational account number.
The user is then asked to fill in a copyright form that maintains details of the transaction and they then
submit this to the LIBSYS system.
The copyright form is c hecked and, if OK, the PDF version of the article is d ownloaded to the LIBSYS
working area on the userÕscomputer and the user is informed that it is available. The user is asked to select
a printer and a copy of the article is printed. If the article has been flagged as Ōprint-onlyÕit i s deleted from
the userÕs system once the user has confirmed that printing is complete.
LIBSYS scenario (2)

What can go wrong: The user may fail to fill in the copyright form correctly. In this case, the form should
be re-presented to the user for correction. If the resubmitted form is s till incorrect then the userÕsrequest
for the article is rejected.
The payment may be rejected by the system. The userÕs er quest for the article is rejected.
The article download may fail. Retry until successful or the user terminates the session.
It may not be possible to print the article. If t he article is not flagged as Ōprint-onlyÕthen it is held in the
LIBSYS workspace. Otherwise, the article is d eleted and the userÕs account credited with the cost of the
article.
Other activities: Simultaneous downloads of other articles.
System state on completion: User is logged on. The downloaded article has been deleted from LIBSYS
workspace if it has been flagged as print-only.
Use cases
• Use-cases are a scenario based technique in the
UML which identify the actors in an interaction
and which describe the interaction itself.
• A set of use cases should describe all possible
interactions with the system.
• Sequence diagrams may be used to add detail
to use-cases by showing the sequence of event
processing in the system.
Article printing use-case
LIBSYS use cases
Article printing
Print article sequence
Social and organisational
factors
• Software systems are used in a social and
organisational context. This can influence or
even dominate the system requirements.
• Social and organisational factors are not a
single viewpoint but are influences on all
viewpoints.
• Good analysts must be sensitive to these factors
but currently no systematic way to tackle their
analysis.
Ethnography
• A social scientists spends a considerable time observing
and analysing how people actually work.
• People do not have to explain or articulate their work.
• Social and organisational factors of importance may be
observed.
• Ethnographic studies have shown that work is usually
richer and more complex than suggested by simple
system models.
Focused ethnography
• Developed in a project studying the air
traffic control process
• Combines ethnography with prototyping
• Prototype development results in
unanswered questions which focus the
ethnographic analysis.
• The problem with ethnography is that it
studies existing practices which may have
some historical basis which is no longer
relevant.
Ethnography and prototyping
Scope of ethnography
• Requirements that are derived from the
way that people actually work rather
than the way I which process definitions
suggest that they ought to work.
• Requirements that are derived from
cooperation and awareness of other
people’s activities.
Requirements validation
• Concerned with demonstrating that the
requirements define the system that the
customer really wants.
• Requirements error costs are high so
validation is very important
– Fixing a requirements error after delivery
may cost up to 100 times the cost of fixing an
implementation error.
Requirements checking
• Validity. Does the system provide the functions which
best support the customer’s needs?
• Consistency. Are there any requirements conflicts?
• Completeness. Are all functions required by the
customer included?
• Realism. Can the requirements be implemented given
available budget and technology
• Verifiability. Can the requirements be checked?
Requirements validation
techniques
• Requirements reviews
– Systematic manual analysis of the
requirements.
• Prototyping
– Using an executable model of the system to
check requirements. Covered in Chapter 17.
• Test-case generation
– Developing tests for requirements to check
testability.
Requirements reviews
• Regular reviews should be held while the
requirements definition is being formulated.
• Both client and contractor staff should be
involved in reviews.
• Reviews may be formal (with completed
documents) or informal. Good communications
between developers, customers and users can
resolve problems at an early stage.
Review checks
• Verifiability. Is the requirement
realistically testable?
• Comprehensibility. Is the requirement
properly understood?
• Traceability. Is the origin of the
requirement clearly stated?
• Adaptability. Can the requirement be
changed without a large impact on other
requirements?
Requirements management
• Requirements management is the process of managing
changing requirements during the requirements
engineering process and system development.
• Requirements are inevitably incomplete and
inconsistent
– New requirements emerge during the process as business needs
change and a better understanding of the system is developed;
– Different viewpoints have different requirements and these are
often contradictory.
Requirements change
• The priority of requirements from
different viewpoints changes during the
development process.
• System customers may specify
requirements from a business perspective
that conflict with end-user requirements.
• The business and technical environment
of the system changes during its
development.
Requirements evolution
Enduring and volatile
requirements
• Enduring requirements. Stable requirements
derived from the core activity of the customer
organisation. E.g. a hospital will always have
doctors, nurses, etc. May be derived from
domain models
• Volatile requirements. Requirements which
change during development or when the
system is in use. In a hospital, requirements
derived from health-care policy
Requirements classification

Requirement Description
Type
Mutable Requirements that change because of changes to the environment in which the
requirements organisation is operating. For example, in hospital systems, the funding of patient
care may change and thus require different treatment information to be collected.
Emergent Requirements that emerge as the customer's understanding of the system develops
requirements during the system development. The design process may reveal new emergent
requirements.
Consequential Requirements that result from the introduction of the computer system. Introducing
requirements the computer system may change the organisations processes and open up new ways
of working which generate new system requirements
Compatibility Requirements that depend on the particular systems or b usiness processes within an
requirements organisation. As these change, the compatibility requirements on the commissioned
or delivered system may also have to evolve.
Requirements management planning
• During the requirements engineering process, you have
to plan:
– Requirements identification
• How requirements are individually identified;
– A change management process
• The process followed when analysing a requirements change;
– Traceability policies
• The amount of information about requirements relationships that
is maintained;
– CASE tool support
• The tool support required to help manage requirements change;
Traceability
• Traceability is concerned with the relationships between
requirements, their sources and the system design
• Source traceability
– Links from requirements to stakeholders who proposed these
requirements;
• Requirements traceability
– Links between dependent requirements;
• Design traceability
– Links from the requirements to the design;
A traceability matrix

Req. 1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2


id
1.1 D R
1.2 D D D
1.3 R R
2.1 R D D
2.2 D
2.3 R D
3.1 R
3.2 R
CASE tool support
• Requirements storage
– Requirements should be managed in a secure, managed data
store.
• Change management
– The process of change management is a workflow process
whose stages can be defined and information flow between
these stages partially automated.
• Traceability management
– Automated retrieval of the links between requirements.
Requirements change management

• Should apply to all proposed changes to


the requirements.
• Principal stages
– Problem analysis. Discuss requirements
problem and propose change;
– Change analysis and costing. Assess effects of
change on other requirements;
– Change implementation. Modify
requirements document and other
documents to reflect change.
Change management
The Software Requirement
Specification (SRS)
Dicuplik dari buku
Software Requirements
Alan M. Davis
Pendahuluan(1)
• Sebelum fase requirement selesai,
dokumen SRS harus dibuat.
• SRS berisi deskripsi lengkap kelakuan
(behavior) eksternal dari sistem software.
• Tujuan dokumen SRS tergantung dari
siapa yang menulisnya. Pertama, SRS
dapat ditulis oleh user (customer) dari
sistem
Pendahuluan(2)
• Kedua, SRS dapat ditulis oleh developer
dari sistem.
• Dua skenario ini berisi situasi yang sangat
berbeda dan tujuan berbeda.
• Yang pertama, bertujuan untuk
mendefinisikan kebutuhan.
• Yang kedua, bertujuan sebagai langkah
awal proses pengembangan software
Tujuan SRS
• Sebagai alat untuk
– komunikasi antar customer, user, analis dan
desainer
– Mendukung aktivitas system testing
– Mengontrol evolusi dari sistem
SRS sebagai komunikasi
antar…
• SRS yang baik mengurangi probabilitas
customer kecewa dengan final product
• SRS sebaiknya sangat spesifik di dalam
bagaimana sistem bekerja di lingkungan
sistem atau user
Note bila Anda memakai
Desain

WARNING: THE “DESIGN” CONTAINED


HEREIN IS SUPPLIED AS AN AID IN
UNDERSTANDING THE PRODUCT’S
EXTERNAL BEHAVIOR ONLY. THE
DESIGNERS MAY SELECT ANY DESIGN
THEY WISH PROVIDED IT BEHAVES
EXTERNALLY IN A MANNER IDENTICAL TO
THE EXTERNAL BEHAVIOR OF THE ABOVE
SYSTEM
SRS sebagai basis untuk … (1)
• Tujuan system testing adalah
menstimulasi sistem dengan skenario-
skenario pengujian untuk menunjukkan
apakah sistem memenuhi requirements.
• Jika SRS ambigu atau tidak konsisten
atau ada requirement tertulis tidak
dapat dites, maka system testing tidak
dapat dilakukan
SRS sebagai basis untuk … (2)
• SRS adalah input utama kepada
perencanaan system test dan proses-
proses selanjutnya
SRS membantu mengontrol (1)
• Misalkan produk software sedang dalam
pengembangan, dan customer
mengatakan “Saya ingin software bisa
melakukan X”
• Bagaimana seseorang tahu apakah X
merupakan requirement baru atau lama
? Jawabannya adalah dengan membaca
SRS dan mencarinya
SRS membantu mengontrol (2)
• Apabila X adalah requirement baru
maka harus dilakukan proses untuk (1)
mengupdate SRS, (2) update desain (3)
update kode, dan selanjutnya
• SRS dipakai sebagai satu-satunya definisi
apa yang PL dapat lakukan
Apa Sebaiknya Isi SRS ? (1)
• Secara simpel, SRS harus memuat
deskripsi lengkap dan jelas dari
keseluruhan antarmuka (interface)
ekternal sistem dengan lingkungannya,
termasuk software lain, communication
port, perangkat keras dan human user.
• Ini meliputi 2 tipe requirement :
behavioral dan nonbehavioral
Apa Sebaiknya Isi SRS ? (2)
• Behavioral requirements mendefinisikan apa
yang sistem dapat lakukan. Ini
mendeskripsikan semua input dan output dari
dan ke sistem, begitu juga dengan informasi
bagaimana input dan output berhubungan.
• Dengan kata lain, kita harus mendefinisikan
secara lengkap fungsi transformasi dari sistem
PL yang dispesifikasi.
Apa Sebaiknya Isi SRS ? (3)
• Nonbehavioral requirements
mendefinisikan karakteristik sistem
ketika sistem melakukan tugasnya.
Seperti deskripsi lengkap level efisiensi,
kehandalan, keamanan, maintainability,
portability, visibility, kapasitas dan
banyak lainnya yang diperlukan dari
sistem
Behavioral Requirements (1)
• Behavioral requirements mendefinisikan
dengan jelas
– Input apa yang diharapkan software
– Output apa yang akan dihasilkan software
– Detil hubungan (relationships) antara input
dan output di atas
Behavioral Requirements (2)
• Sebagai contoh, hendak dibangun
sebuah kotak dengan 4 (empat) tombol
dan 2 (dua) lampu.
• Behavioral requirements dari kotak
dinyatakan sbb:
Behavioral Requirements (3)
1) Terdapat 4 (empat) input. 8) Selama “powered off”, B2 dan B3
Disebut tombol. tidak mempunyai pengaruh pada
Tombol diberi nama B1, B2, B3, kelakuan sistem.
dan B4. 9) Ketika powered off, tidak ada lampu
menyala.
2) Terdapat 2 (dua) output. Disebut
lampu. 10) Dalam kondisi powering on, jika B2
dipijit lebih sering daripada B3,
Lampu diberi nama L1 dan L2. maka L1 akan menyala.
3) B1 menjadi tombol “power on” . 11) Dalam kondisi powering on, jika B3
4) B4 menjadi tombol “power off” . dipijit lebih sering daripada B2,
5) B2 dan B3 menjadi tombol maka L2 akan menyala.
“action” 12) L1 dan L2 tidak menyala bersamaan
6) Setelah B1 dipijit tetapi sebelum 13) Jika salah satu lampu rusak, lampu
B4 dipijit, sistem dalam kondisi lain akan berkelap-kelip secara
otomatis. Kelap-kelip berhenti
“powered on.”
ketika B4 dipijit kemudian sistem
7) Sesudah B4 ditekan tetapi restart ketika B1 dipijit. Ketika
sebelum B1 dipijit, sistem dalam lampu rusak diganti, lampu akan
kondisi “powered off.” berhenti kelap-kelip dan sistem
berjalan seperti biasa.
Behavioral Requirements (4)
• Contoh di atas merupakan deskripsi
kelakuan (behavior) dari sebuah sistem
trivial dalam bahasa Inggris.
• Semakin kompleks sebuah sistem,
semakin sulit juga menjelaskan kelakuan
supaya tidak ambigu.
• Perhatikan contoh di atas.
(ada pertanyaan ?)
Solusinya ?
• Membuat model yang mampu
menggambarkan kelakuan sistem.
• Model yang dapat membantu kita
dengan tingkat yang lebih tinggi
daripada penggunaan bahasa alami
seperti bahasa Inggris di atas.
Teknik-Teknik yang ada
• State-Oriented
– Finite state machine (FSM)
– Statecharts
– Petri nets
• Function-Oriented
– Decision tables and decision trees
– Program design language (PDL)
– Requirements Language Processor (RLP)
– Specification and Description Language (SDL)
• Object-oriented
– Statecharts
– Activity Diagrams
– Statechart Diagrams
Pergi kuliah Akuntansi

[memilih akuntansi] [menyadari bahwa kamu


tidak suka akuntansi]

Siap untuk kuliah [memilih jadi programmer]


Pilih Karir Pergi kuliah IT

[kerja di toko]

Bekerja Belajar di kampus


Apa yang sebaiknya TIDAK
dimasukkan dalam SRS ?
• Project requirements (contohnya,
staffing, jadwal, biaya, milestones,
aktivitas, fase, prosedur pelaporan)
• Desain
• Product assurance plans (contohnya,
rencana manajemen konfigurasi,
rencana verifikasi dan validasi (V&V),
test plan, quality assurance plans)
Mengapa project requirements
TIDAK dimasukkan dalam SRS ?
• Karena SRS dan project requirements
mempunyai life span yang sangat
berbeda
• Life span SRS sama dengan Life span dari
produk, contohnya, 5 tahun, 10 tahun, 15
tahun dan seterusnya
• Milestones, biaya pengembangan, dan
staffing hanya selama pengembangan
proyek
Mengapa desain TIDAK
dimasukkan dalam SRS ? (1)
1) Keuntungan utama dari pemisahan
desain dari SRS adalah kemampuan
untuk mendefinisikan baseline dalam
proses pengembangan yang (1)
menandai milestone dari proyek dan
menandai kemajuan dan (2) dapat
digunakan untuk mengontrol
perubahan pada sistem
Mengapa desain TIDAK
dimasukkan dalam SRS ? (2)
2) Requirement dan spesifikasi desain
mempunyai target audience yang
berbeda. Audience SRS meliputi
pengguna sistem, system tester,
customers, desainer, dan requirements
writer sendiri. Audience untuk
dokumentasi desain meliputi unit dan
integrasi tester, coder, dan desainer
Mengapa desain TIDAK
dimasukkan dalam SRS ? (3)
3) Requirements writer dipilih karena
kemampuannya untuk menganalisa
dan menspesifikasi, bukan
kemampuan memilih desain yang
efisien. Proses mencari desain yang
cocok memerlukan kompromi yang
hati-hati dari banyak faktor dan
mungkin menghabiskan 15%-20% dari
total biaya pengembangan.
Mengapa product assurance plans
TIDAK dimasukkan dalam SRS ?
• Dua alasan utama sama dengan sebelumnya.
Tidak relevan apabila menggabungkan subjek-
subjek yang tidak berhubungan dalam dokumen
yang sama dan audience untuk product assurance
plan berbeda dengan audience SRS.
• Produk assurance plan sebaiknya didokumentasi
dalam S/W Quality Evaluation Plan (SQEP), the
S/W Configuration Management Plan (SCMP), dan
the S/W Test Plan (STP)
Karakteristik dari SRS yang
Baik
• SRS dikatakan baik apabila SRS
– Correct – Modifiable
– Unambiguous – Traced
– Complete – Traceable
– Verifiable – Design
– Consistent independent
– Understandable – Annotated
by customer
– Concise
– Organized
Correct (1)
• Sebuah SRS adalah correct jika dan
hanya jika setiap requirement yang
terdapat di dalamnya
merepresentasikan requirement yang
dibutuhkan sistem untuk dibangun.
• Tidak ada cara untuk mengajarkan
kualitas ini, karena kualitas ini
tergantung total pada aplikasi
Correct (2)
• Jika software harus merespon pijitan
tombol dalam 5 detik dan SRS
menyatakan bahwa
“The software shall respond to all
button presses within 10 seconds”
maka requirements incorrect.
• Diagram Venn
User’s A B C SRS
Needs Requirements
Unambiguous
• Dokumen SRS unambiguous jika dan hanya
jika semua requirement yang tertulis di
dalamnya hanya mempunyai satu interpretasi.
• Contoh 1. Masalah Air Traffic Controller
“For up to 12 aircraft, the small display format
shall be used. Otherwise, the large display format
shall be used.”

• Contoh 2. Masalah Nonfriendly Aircraft


“Aircraft that are nonfriendly and have an unknown
mission or the potential to enter restricted
airspace within 5 minutes shall raise an alert.”
Complete (1)
• Dokumen SRS complete jika SRS
mempunyai 4 kualitas:
1. Semua kemampuan software yang
diharapkan termuat dalam SRS.

User’s A B C SRS
Needs Requirements

Completeness menyatakan bahwa daerah A


mempunyai luas kosong/nol. Perhatikan
bahwa jika SRS complete dan correct maka
daerah A dan C adalah hampa dan dua
lingkaran berhimpit.
Complete (2)
Completeness adalah karakteristik yang paling susah
untuk didefinisikan atau dideteksi kesalahannya.
Sebuah kesalahan sulit untuk dideteksi karena artinya
ada sesuatu yang tidak tertulis dalam SRS; sulit untuk
mencari sesuatu yang tidak kelihatan dengan
mengamati yang kelihatan.
• Contoh:
“If party A calls party B and party B is idle, then
party B’s phone shall ring”

“If party A calls party B and party B is idle, then


party B’s shall ring and no other phone shall ring”
Complete (3)
2. Definisi respon software terhadap semua
input data termuat di dalam SRS. Buat
spesifikasi respon untuk input valid dan
invalid. Artinya, setiap input untuk sistem
yang dijelaskan dalam SRS. SRS
menspesifikasikan output yang sesuai
dengannya.
3. Namun, output yang sesuai mungkin juga
fungsi dari current state dari sistem. Contoh,
dalam sistem telephone switching.
Complete (4)
3. Semua halaman diberi nomor; semua
gambar dan tabel diberi nomor, diberi
nama, dan diacu; semua istilah dan unit
pengukuran disediakan; dan semua material
dan sections yang diacu tersedia. Ini
completeness dari perspektif word processing.
4. Tidak ada section yang ditandai To Be
Determined (TBD)
Verifiable (1)
• Dokumen SRS verifiable, jika dan hanya
jika, setiap requirement yang disebutkan
di dalamnya verifiable. Sebuah
requirement verifiable, jika dan hanya
jika, ada proses dengan biaya terbatas
sehingga seseorang atau mesin dapat
mengecek apakah software yang sedang
dibuat memenuhi requirement atau
tidak.
Verifiable (2)
• Ada beberapa alasan mengapa
requirement mungkin tidak verifiable.
Pertama, ambiguity akan menyebabkan
tidak verifiable.
• Contoh:
“The product shall have an easy-to-use human
interface”

• Kedua, penggunaan kata-kata yang


tidak dapat diukur seperti “usually” atau
“often”
Consistent (1)
• Dokumen SRS konsisten jika dan hanya
jika
1) Tidak ada requirement yang tertulis di
dalamnya konflik dengan dokumen
sebelumnya seperti system requirements
specification or a statement of work
2) Tidak ada himpunan bagian dari
requirement tertulis yang konflik
Consistent (2)
• Ada empat tipe dari incompleteness:
1. Conflicting behavior: Dua bagian dari SRS
menspesifikasi perbedaan stimulus untuk
menghasilkan responsi tertentu atau
menspesifikasi perbedaan respon untuk stimulus
dan kondisi yang sama.
Contoh 1
- The light shall be lit when and only when the
button is pressed.
- When the button is released, the light shall
become lit

TIDAK KONSISTEN !
Consistent (3)
Contoh 2
- When the phone is lifted, a dial tone shall be
generated.
- When the phone is lifted, a ringing tone shall
be generated.
TIDAK KONSISTEN !
2. Conflicting terms: dua istilah digunakan dalam
konteks yang berbeda dan mempunyai arti yang
sama. Contohnya, istilah “prompt” untuk
menggambarkan pesan yang ditampilkan oleh
S/W untuk meminta pengguna memasukkan
informasi. Ada juga “cue”.
Consistent (4)
3. Conflicting characteristics:
Contoh: di satu tempat, SRS menyatakan
bahwa
“all inputs to the software
shall be via selection of an
option in a displayed menu,”
dan di tempat lain, “ the user
command language shall
consist of the following
typed commands …”
Consistent (5)
4. Temporal inconsistency:
Dua bagian dari SRS bertentangan dalam
karakteristik waktu. Contoh, SRS
menyatakan “system input A will
occur only while system input B
is occuring,” dan di tempat lain
dalam SRS menyatakan “system input
B may start 15 seconds after an
occurrence of system input A”
Understandable by Customers
• Dalam membuat SRS yang lebih tidak
ambigu, lebih verifiable, complete, dan
konsisten, kita mungkin menggunakan notasi
formal sekali
• Sayang sekali notasi tersebut membuat
bingung non computer specialist untuk
memahami SRS
• Pembaca utama dari SRS adalah customer
atau pengguna, yang cenderung jago dalam
bidang aplikasi tetapi tidak sepenuhnya bisa
dalam computer science.
Modifiable (1)
• SRS modifiable jika struktur dan gaya SRS
sedemikian sehingga perubahan pada
requirement dapat dibuat easily, completely,
dan consistently.
• Modifiability artinya ada daftar isi, indeks, dan
referensi jika memungkinkan.
• Contoh:
Jika kita ingin merubah maksimum respond time of a
dial tone in a telephone switching system from 5
detik ke 3 detik, kita akan mencari di indeks
dengan kata “dial tone”
Modifiable (2)
• Salah satu teknik yang dapat digunakan
untuk meningkatkan kemudahan membaca
SRS adalah dengan mengulangi selected
requirements in different locations in the
document. Karakteristik ini disebut
redundancy.
Contoh:
Ketika mendeskripsikan eksternal view dari
local call, SRS menyatakan:
Modifiable (3)
“Starting with an idle telephone, the user
should lift the handset, the system shall
respond with a dial tone, then the user should
dial the seven digit phone number of the party
the user is trying to reach … ”
Ketika mendeskripsikan eksternal view dari
long distance call, SRS menyatakan:
“Starting with an idle telephone, the user
should lift the handset, the system shall
respond with a dial tone, then the user should
dial a 1 followed by the ten digit phone
number of the party the user is trying to
reach … ”
Traced (1)
• Sebuah dokumen SRS traced jika asal
(origin) dari setiap requirements jelas
(clear). Artinya, SRS mencakup acuan ke
dokumen-dokumen pendukung awal,
seperti dalam gambar di bawah.

traceable
System level
Design
Requirements, SRS Documents
white paper, etc

traced traceable
Traced (2)
• Contoh: SRS mencakup requirement
“The system shall respond to any occurrence
of request X within 20 seconds.”
Sekarang software sudah dibangun dan ketika
software diuji dalam final test, response time
diukur secara konsisten pada 60 detik. Ada 2
cara untuk memperbaiki masalah ini
1) esain ulang atau kode ulang software supaya
lebih efisien
2) Ubah requirement dari 20 menjadi 60 detik
Traceable (1)
• Dalam mendesain atau menguji
komponen dari perangkat lunak, perlu
diketahui bagi kita requirements mana
saja yang sudah ada komponennya.
Dalam pengujian sistem software, perlu
diketahui bagi kita requirements mana
saja yang sudah divalidasi oleh setiap tes
Traceable (2)
• Dokumen SRS traceable jika setiap
requirement di dalam SRS dapat diacu
• Ada variasi teknik untuk melakukan ini:
– Beri nomor setiap paragraf secara hierarki
– Beri nomor setiap paragraf secara hierarki dan
jangan memuat lebih dari satu requirement di
dalam paragraf
– Beri nomor setiap requirement dgn nomor unik
dalam kurung
– Gunakan aturan yang disepakati mengenai
requirement, contohnya kata “shall”
Design Independent
• Dokumen SRS design independent jika
SRS tidak memakai arsitektur atau
algoritma spesifik.
• Contohnya, SRS sebaiknya jangan
menyebut
“The system shall be composed of the
components X, Y, and Z.”
Pemberian Penjelasan
(Annotated)
• Pemberian penjelasan requirement
dalam SRS memberikan panduan untuk
organisasi pengembangan software.
• Salah satu cara melakukan ini adalah
dengan menambahkan ke setiap
requirement dalam SRS, huruf E, D atau
O dalam kurung untuk essential,
desirable, atau optional
Concise
• Diberikan dua SRS untuk sistem yang
sama, masing-masing menunjukkan
level yang sama dari kualitas-kualitas
yang dijelaskan sebelumnya. SRS yang
lebih singkat lebih baik
Organized
• Sebuah SRS organized jika requirements
yang termuat di dalamnya mudah
untuk ditemukan (easy to locate)