17
Requirement TIF-151551 REKAYASA DAN MANAJEMEN KEBUTUHAN
RequirementTIF-151551
REKAYASA DAN MANAJEMEN KEBUTUHAN
Motivation
“The hardest single part of building a system is
deciding precisely what to build”
[Brooks – 1987]
Rekayasa dan Manajemen Kebutuhan | Pengantar
2
What is requirement
� IEEE-STD-1220-1998:
a statement that identifies a product or process operational, functional, or design characteristic or constraint, which is unambiguous, testable or measurable, and necessary for product or process acceptability (byconsumers or internal quality assurance guidelines).
� CMMI (Capability Maturity Model Integration) version 1.3:
i. a condition or capability needed by a user to solve a problem or achieve an objective,
ii. a condition or capability that must be met/possessed by a product, service, product component or service component to satisfy a supplier agreement, standard, specification or other formally imposed documents,
iii. a documented representation of a condition or a capability as in (i) or (ii) above.
3
Rekayasa dan Manajemen Kebutuhan | Pengantar
Requirements – wicked problems
� Most large software systems address wicked problems
� Problems which are so complex that they can never be fully understood and where understanding develops during the system development
� Therefore, requirements are normally both incomplete and inconsistent
4
Rekayasa dan Manajemen Kebutuhan | Pengantar
Reasons for inconsistency
� Large software systems must improve the current situation. It is hard to anticipate the effects that the new system will have on the organisation
� Different users have different requirements and priorities. There is a constantly shifting compromise in the requirements
� System end-users and organisations who pay for the system have different requirements
� Prototyping is often required to clarify requirements
5
Rekayasa dan Manajemen Kebutuhan | Pengantar
Classification based on detail levels
� User requirements
� Statements, in natural language plus diagrams, of of what services
the system is expected to provide to system users and the
constraints under which it must operate.
� System requirements
� More detailed descriptions of the software system’s functions,
services, and operational constraints.
6
Rekayasa dan Manajemen Kebutuhan | Pengantar
Different potential readers
7
Rekayasa dan Manajemen Kebutuhan | Pengantar
Example – mental health care
patient mgmt system (MHC-PMS)
Rekayasa dan Manajemen Kebutuhan | Pengantar
8
Requirements level
� Normal requirement � kebutuhan yang harus dipenuhi dan
dinyatakan secara eksplisit
� Fungsionalitas sistem, unjuk kerja
� Expected requirement � kebutuhan yang tidak dinyatakan
secara eksplisit tetapi menentukan kepuasan customer
� Kemudahan interaksi dengan sistem, correctness
� Exciting requirement � kebutuhan yang melebihi dari
kebutuhan normal untuk lebih memuaskan customer
� Fungsionalitas tambahan sistem
Rekayasa dan Manajemen Kebutuhan | Pengantar
9
Classification based on functionality
� 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 (NFRs)
� Constraints on the services or functions offered by the system such
as timing constraints, constraints on the development process,
standards, etc.
10
Rekayasa dan Manajemen Kebutuhan | Pengantar
Types of NFRs
Rekayasa dan Manajemen Kebutuhan | Pengantar
11
NFRs 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.
Rekayasa dan Manajemen Kebutuhan | Pengantar
12
NFRs examples
� Product requirements
� The MHC-PMS shall be available to all clinics during normal working hours (Mon–Fri, 08.30–17.30). Downtime within normal working hours shall not exceed five seconds in any one day.
� Organisational requirements
� Users of the MHC-PMS system shall authenticate themselves using their health authority identity card.
� External requirements
� The system shall implement patient privacy provisions as set out in HStan-03-2006-priv.
Rekayasa dan Manajemen Kebutuhan | Pengantar
13
Requirements verifiability
� Requirements should be written so that they can be objectively verified
� The problem with this requirement is its use of vague terms such as ‘errors shall be minimised”
� The system should be easy to use by experienced controllers and should be organised in such a way that user errors are minimised.
� The error rate should be been quantified
� Experienced controllers should 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 should not exceed two per day.
Rekayasa dan Manajemen Kebutuhan | Pengantar
14
NFRs metrics
Rekayasa dan Manajemen Kebutuhan | Pengantar
15
Requirements evolution
� Requirements always evolve as a better understanding of
user needs is developed and as the organisation’s objectives
change
� It is essential to plan for change in the requirements as the
system is being developed and used
Rekayasa dan Manajemen Kebutuhan | Pengantar
16
C h an g e du n d er s ta n d i n g
o f p ro b l em
I n i ti a lu n d er s ta n d i n g
o f p r o b l em
C h an g e dr e q u ir e m e n t s
I n i ti a lr e q u ir e m e n t s
T i m e
Controlled evolution
Rekayasa dan Manajemen Kebutuhan | Pengantar
17
System
implementation V1
System
implementation V2
System
implementation V1
System
implementation V2
Requirements
document V1
Requirements
change
Requirements
document V1
Requirements
document V2
Requirementschange
Requirements and systeminconsistent
Requirements and systemconsistent
