Transcript Rekayasa Kebutuhan Perangkat Lunak

Daniel Siahaan
February 2012
Content
 Introduction to Requirements Engineering
 Perspektif Stakeholder
 Requirements Elicitation
 Requirements Analysis
 Requirements Specification
 Requirements Validation
SMART Requirements
 Non-functional requirements is born to be
disputable.
 Using the SMART framework a document can be
checked and every requirement can be verified as
correct in terms of expression (but not content).
 Specific Measurable Attainable, Realisable, and
Traceable Requirements
Specific Requirements
 A requirement must say exactly what is required
 Clear, i.e. there is no ambiguity
 Consistent, i.e. the same terminology has been used
throughout the specification to describe the same
system element or concept
 Simple, i.e. avoid double requirement, e.g. X and Y
 Of an appropriate level of detail
Guideline for Specific Requirements








Avoid phrases like: obviously, clearly, certainly
Avoid ambiguities like: some, several, many
Avoid list terminators like: etc, and so on, such as
Ensure pronouns are clearly referenced, e.g. “When
module A calls B, its message history file is
updated”
When numbers are specified identify the units
Ensure all possible elements in a list are described
Use pictures to clarify understanding
Ensure all system or project terms are defined in
glossary
Guideline for Specific Requirements
 Consider placing individual requirements in
separate paragraph and individually numbered
 Ensure vers such as “transmitted”, “sent,
“downloaded”, “processed” are qualified by
precise explanations
 Only use the word “details”, “information”, “data”
in a requirement when you can describe or refer
to precisely what they will be
 If the requirement is described by a prototype
program, ensure that specific program is
documented
Guideline for Specific Requirements
 When a term is defined in a glossary, substitute
the definition in the text and then review the
requirement
 No “To be defined”
“The Mission Planning System shall support
several planning environments for generating
the mission plan” (bad)
“The system shall support 50 simultaneous users.
“ (better)
Measurable Requirements
 Is it possible, once the system has been
constructed, to verify that this requirement has
been met.
Guideline for Measurable
Requirements
 What other requirements need to be verified before
this requirements Can this requirements be
verified as part of the verification for another
requirements?
 How much data or what test cases are required?
 How much processing power is required?
 Can the test be conducted on one site?
 Can this requirement be tested in isolation?
Attainable Requirements
 Is it possible physically for the system to exhibit
that requirement under the given conditions.
 Some requirement may be beyond the bounds
of human knowledge or only have a theoretical
solutions beyond what is currently achievable.
Guideline for Attainable Requirements
 Is there a theoretical solution to the problem?
 Has it been done before? If not, why not?
 Has a feasibility study been done?
 Is there an overriding constraint which
prohibits this requirement?
 Are there physical constraints on the size of the
memory, processor, or peripherals?
 Are there environmental constraints such as
temperature, compressed air?
Guideline for Attainable Requirements
“The system shall be 100% reliable and 100%
available.” (bad)
“The system shall have a minimum response to a
query of 1 second irrespective of system
load.”(better)
Realizable Requirements
 Is it possible to achieve this requirement given what
is known about the constraints under which the
system and the project must be developed
 It is often considered in parallel with attainable,
but does not however make them synonymous
Guideline for Realizable Requirements
 Determine who has responsibility for satisfying the
requirement
 Can they deliver?
 Can we afford to manage them?
 How badly is it needed?
 Are there sufficient resources?
 Are we constrained to a particular package which
does not support this requirement?
 Can we reuse from other projects?
Guideline for Realizable Requirements
 The requirements are often placed into one of the
categories:
 Essential
 Desirable
 Or sometime
 Mandatory
 Optional
Guideline for Realizable Requirements
“The system must have ten operator chairs.” –
Essential
“The operator chairs should be red.” - Desirable
Traceable Requirements
 Is the ability to trace (forwards and backwards) a
requirement from its conception through its
specification, to its subsequent design,
implementation, and test.
 So that we can know and understand the reason each
requirement’s inclusion within the system
 So that we can verify that each requirement has been
implemented
 So that modifications are made easily, consistently,
and complete.
Parties Who is Interested
SMART user
S
M
Procurer

Analysis

Designer

Project Manager


Quality Manager


Test Engineer


Maintainer

End User

A
R
T













Personal Exercise
 List the non-functional requirements out of your
group’s project
Project Management
Source: Forsberg, 1997
 Successful projects usually use 7 to 15% of project
resources (Forsberg, 1997)
 On average, projects use 8% of total project resources,
during the period of time averaging 20% (Boehm,
2000)