Requirement TIF REKAYASA DAN MANAJEMEN KEBUTUHAN

Ukuran: px

Mulai penontonan dengan halaman:

Download "Requirement TIF REKAYASA DAN MANAJEMEN KEBUTUHAN"

Iwan Lesmono
6 tahun lalu
Tontonan:

1 Requirement TIF REKAYASA DAN MANAJEMEN KEBUTUHAN

2 2 Motivation The hardest single part of building a system is deciding precisely what to build [Brooks 1987]

3 3 What is requirement IEEE-STD : 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 (by consumers 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.

4 4 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

5 5 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

6 6 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.

7 7 Different potential readers

8 Example mental health care patient mgmt system (MHC-PMS) 8

9 9 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

10 10 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.

11 11 Types of NFRs

12 12 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.

13 13 NFRs examples Product requirements The MHC-PMS shall be available to all clinics during normal working hours (Mon Fri, ). 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 priv.

14 14 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.

15 15 NFRs metrics

16 16 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 I n i ti a l u n d er s ta n d i n g o f p r o b l em I n i ti a l r e q u ir e m e n t s C h an g e d u n d er s ta n d i n g o f p ro b l em C h an g e d r e q u ir e m e n t s Tim e

17 17 Controlled evolution Requirements change Requirements document V1 System implementation V1 Requirements change System implementation V2 Requirements and system inconsistent Requirements document V1 Requirements document V2 System implementation V1 System implementation V2 Requirements and system consistent

dokumen-dokumen yang mirip

REQUIREMENT ENGINEERING

REQUIREMENT ENGINEERING Previous Chapter Poor Quality software? Not meet customer requirements Too complicated Not solve the problem Beyond expectation Requirement engineering is very important! Requirements