Pertemuan 3 System Engineering : Business Process Engineering, Requirements Engineering
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 g CASE and 4GTs,, testing g
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 refine model and clustering g
area
Defining Objectives and Goals •
Objective—general statement of direction
•
Goal—defines measurable objective: “reduce manufactured a u ac u ed cos cost o of ou our p product” oduc Subgoals: Ð decrease reject rate by 20% in first 6 months Ð gain 10% price concessions from suppliers Ð re-engineer i 30% off components t ffor ease off manufacture f t d during i fifirstt 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 d fi i systems that h are iincompatible ibl with i h new iinformation f i model begin to establish re-engineering priorities
The BAA Process admin.
sales
manufacturing QC
distribution
acct
eng’ring
Process Flow Models
Data Model
Process P Decomp. Diagram
Matrices e.g., entity/process matrix
Product Engineering The complete product
System analysis (World view)
capabilities
hardware
Component engineering (Domain view)
software
Processing requirement
data
function
behavior
Analysis & Design Modeling (Element view)
program component
Construction & Integration (Detailed view)
Software Engineering
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 q
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 processing
d control t l process and functions
maintenance and self-test
output processing
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 bar code reader subsystem
bar code decoding subsystem
timing/location data
report requests
shunt control subsystem
part number
raw bar b code data bar code
sensor data acquisition subsystem y
line speed
bin location
data base access subsystem key
report formating subsystem
sort records
pulse tach input
data acquisition interface
bar code reader status
diagnostics subsystem
shunt commands
CLSS reports
mainframe i f communications driver
BCR status sensor status
shunt controller
shunt status communications status
diagnostic interface
formated reporting data
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 May be the basis for the contract itself ‐ detail; Both these statements may be called requirements.
Requirements abstraction (Davis) “If a comp a ny w ish e s to le t a cont ra ct fo r a la rg e so ft w ar e deve lopmen t p roje c t, i t mu s t d ef ine its need s in a su ffi cien tly ab stra ct w ay that a so lution is no t p re-de fi ned. Th e r equi re men ts m us t be wr it ten so that sev er al c ont rac to rs can b id fo r the con tr ac t, o ff eri ng, pe rhap s , di ff ere nt w ay s o f me e ting the c lien t o rgani sation ’s need s. O nce a con tr ac t ha s been a w ard e d, the c ont rac to r mu s t wr ite a s y s te m de fin ition fo r th e cl ient in m o re de tai l so that the c lient und er stand s and c a n val idat e wh a t th e so ft w ar e w ill do. Both o f t he se docu m ent s m a y be ca lled the requi rem en ts do c um e nt fo r th e sys tem. ”
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 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 and non‐functional requirements •
Functional requirements •
•
Non‐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.
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. q y
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. 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 d documents d t in i the th document d t store. t
•
Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be able to copy to the account account’ss 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 yp ; type; Developer interpretation ‐ Provide a text viewer that shows the contents of the document.
R Requirements completeness and consistency i t l t d i t •
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 Non‐functional requirements •
These define system properties and constraints e.g. reliability, response time and storage requirements. Constraints are I/O ti d t i t C t i t I/O device capability, system representations, etc.
•
Process requirements may also be specified mandating a q y p g particular CASE system, programming language or development method.
•
Non functional requirements may be more critical than Non‐functional requirements may be more critical than functional requirements. If these are not met, the system is useless.
Non functional classifications Non‐functional classifications •
Product requirements •
•
Organisational requirements •
•
Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc.
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 Non‐functional requirements examples •
Product requirement 8.1 The user interface for LIBSYS shall be implemented as simple HTML without frames or Java p p 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 77.6.5 The system shall not disclose any personal information about customers apart from their name 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 i imprecise requirements may be difficult to verify. i i t b diffi lt t if
•
Goal •
•
Verifiable non‐functional requirement •
•
A general intention of the user such as ease of use. g
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 Pr op er t y
M ea su r e
S p e ed
P ro ce ss e d tra ns ac tio n s /se co n d Us er /Ev U /E e ntt r e sp o ns e tim ti e S c r ee n r e fr e sh t im e
S iz e
M B y te s N u mb er o f R O M ch ip s
Ea s e o f us e
T r ai n in g tim e N u mb er o f h el p fr a m e s
R e li a bi lity
M e an ti m e to f ail ur e P ro b a b ili ty of u n a v ai lab ili ty R a te of fa il ur e o ccu rr en c e A va ila b ilit y
R o b us tn e ss
Ti me t o r e s ta r t af te r f ai lu r e P e r ce n ta g e o f e ve n ts c au si n g f ai lu r e P ro b a b ili ty of d a ta c o r ru p tio n o n fa il u re
P o r ta bi lity
P e r ce n ta g e o f ta r ge t d epe n d e n t s ta te m e n ts N u mb er o f ta rg et s y s te m s
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 T i i i i ht th b f t hi i th t should be minimised. To minimise power consumption, lower power chips should be used. H However, using low power chips may mean that more chips have to i l hi th t hi h t 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 q , y y 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 d l t d immediately deleted i di t l on arrival. i l Depending D di on the th user’s ’ requirements, these documents will either be printed locally on the system server for manually forwarding to the user or routed t d to t a network t k printer. i t
Train protection system •
The deceleration of the train shall be computed as: •
Dtrain = Dcontrol + Dgradient
where Dgradient is 9 9.81ms2 * compensated p gradient/alpha g / p 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 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 •
•
Requirements confusion •
•
Precision is difficult without making the document difficult to read. F ti Functional and non‐functional requirements tend to be mixed‐up. l d f ti l i t t d t b i d
Requirements amalgamation •
Several different requirements may be expressed together. 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 f h h l may receive discounted rates.
Editor grid requirement 22.6 Grid facilities 6 Grid facilities To assist in the positioning of entities on a diagram, 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 gg y g p 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 i f information ti • •
•
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 However, it also includes the detail that managers can configure this system 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 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. 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. t d l di d i Ch t 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 A t hit t b d i d t t t th 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 •
•
Over‐flexibility •
•
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. 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 No t at io n
De s cr ip tio n
St ru c tu r ed na tu r a l g g language
T hi s a pproa c h dep e nds on de fi n ing s ta ndard r equ q ire m e n ts spec p ifi ca ti on.
De si gn de s cr ip ti on language s
T hi s a pproa c h u s es a la nguage li ke a prog r a mmi ng langu a ge bu t w ith m o r e ab st ra c t f ea tu r es t o s pec if y the requ ir e m en ts by def in ing an op e ra ti ona l m ode l o f th e sy st e m . T hi s a pproa c h is no t now w ide ly used a lt hough it c an b e us e fu l fo r in te rf ace sp e c ific at ion s .
G r aphh ica i l no ta ti ons
A graph h ic i a l languag l e , supp le l m en ted t d by b tex t t anno ta t ti ons i s used d t o de d fi ne t he h f unc ti ona l r equ ir e m en ts fo r th e s ys te m . An ea rl y exa m p le o f s uch a g r aph ica l language wa s S AD T . Now , u s e - cas e de s c r ip ti on s and s equence d iag r a m s a r e co mm on ly u s ed .
M at he m a ti ca l sp e c ific ifi att ion i s
T hese a r e no ta tion s ba s ed on m a the m a ti c a l concep ts s uch a s f in it e - s ta te m ach ine s o r s ett s . T hese h una m b iguous i spe cii fica fi ti on s r educe d t he h argu m en ts t b e tw t een c us to t m e r and d con tr ac to r abou t sy st e m f unc ti ona lit y. Howeve r , m os t cus to m e r s don ’ t unde r s tand f or m a l spe ci fica ti on s and a r e r e luc tan t t o a c cep t it as a s ys te m con tr ac t.
f or ms o r te m p la te s to exp r es s the
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 t l l i i t i d b t d f if it i imposed on the specification.
Form based specifications 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. p p yg
•
Indication of other entities required.
•
Pre and post conditions (if appropriate). Pre and post conditions (if appropriate)
•
The side effects (if any) of the function.
Form‐based node specification Insu li n P u m p /C on trol S of tw ar e/ S RS /3. 3 .2 F un ctio n C om pu te in su lin d ose : S afe su ga r lev e l D escr iption C om pu te s th e dos e o f ins ul in to be de liv er e d wh en the cu rren t m ea sur ed su ga r le v el is i n th e safe zo n e b et w ee n 3 a n d 7 u ni ts . Inp p uts
C ur re n t su g ga r re a di n g ((r2 ), th e p re v io us t w o r ea d in ggs ((r 0 a nd r 1))
S ou rc e C ur re n t su ga r re a di n g fro m s en so r. O th e r re a di n gs fro m m em ory. Ou tputs C om pD ose Š th e dos e in insu lin to b e d el ive re d D estin atio n
M ai n co ntro l loo p
A ct ion: C om pD ose is z er o if the sug ar le v el is st ab le o r fa lling or if th e le ve l is inc re as in g b ut th e rat e of i crea se is in i d ec rea sin i g. Iff the h le l v ell is i inc i rea sii ng an d thh e rate off in i crea se is i in i crea sii ng , th h en C om pD ose is i com pu te d by d iv id ing th e d iff er e nc e be tw een th e cu rren t su ga r lev el a nd th e p re v io us le v el by 4 an d rou nd in g the re su lt. If th e result, is rou nd ed to ze ro th en C o m pD ose is set to th e mi ni mum d ose tha t ca n b e d e li v ered . R eq uire s
T w o pr ev ious r ead ings s o th at the ra te of ch an g e o f s ug ar le v el can be co mp uted .
P -con dition Pre di i
T h e i ns ulin li r eservo ir i co nt a in i s at lea l st thh e m ax imum i all low l ed d sin i gle l d ose off i ns ulin li ..
P os t-co ndi tion
r0 is r ep lace d b y r1 th en r1 is re p la ced b y r 2
S id e-effe ct s
N on e
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 increase decreasing ((r2-r1)<(r1-r0))
CompDose = 0
Sugar level increasing and rate of increase stable or increasing increasing. ((r2-r1) ((r2 r1) ≥ (r1-r0))
CompDose = round ((r2-r1)/4) If rounded result = 0 then 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. 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 ti i t f t b ifi d t f th requirements.
•
Three types of interface may have to be defined yp y • • •
•
Procedural interfaces; Data structures that are exchanged; Data representations. p
Formal notations are an effective technique for interface specification.
PDL interface description in t e rf a c e P ri n t Se rv e r { / / d e fi ne s an a bs tr a ct p r in t e r s e r v e r / / r e q u ir es : in t e rf a c e P ri n t e r, in te r f a c e P ri n t D o c / / p r o v id e s : i n it ia l iz e , p r i nt , d is p la y P ri n t Qu e u e , c an c e lP r in tJ ob , s w i tc hP ri n t e r v oi d in it i al i z e ( P r in t e r p ) ; v oi d p ri n t ( P ri n t e r p , P r i nt Do c d ) ; v oi d d is p la y P r i nt Qu e u e ( P r i nt e r p ) ; v oi d c a n c e lP ri n t J o b ( P r i n t er p , P ri n t D o c d ) ; v oi d s w it c h P r in t e r ( P ri n t e r p1 , P ri n t e r p2 , P ri n t D o c d ) ; } // P ri n t Se rv e r
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. 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 y
Users of a requirements document q
IEEE requirements standard •
Defines a generic structure for a requirements document that must be instantiated for each specific system. • • • • •
Introduction. General description. p Specific requirements. Appendices. Index.
Requirements document structure •
Preface
•
I Introduction d i
•
Glossary
•
User requirements definition
•
System architecture
•
System requirements specification
•
System models
•
System evolution
•
Appendices
•
Index
Req irements engineering processes 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 However there are a number of generic activities common to all processes • • • •
Requirements elicitation; R Requirements analysis; i l i Requirements validation; Requirements management.
Th The requirements engineering process i t i i
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 th t t ib t t i ti l bj ti If the system can be engineered using current technology and within budget; If th t b i t If the system can be integrated with other systems that are used. t d ith th t th t d
Feasibility study implementation •
Based on information assessment (what is required), information collection and report writing. ll ti d t iti
•
Questions for people in the organisation • • • • • •
What if the system wasn’t implemented? y p 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 The requirements change during the analysis process New stakeholders may emerge and the business environment change.
The requirements spiral
Process activities •
Requirements discovery •
•
Requirements classification and organisation •
•
Groups related requirements and organises them into coherent clusters.
Prioritisation and negotiation •
•
Interacting with stakeholders to discover their requirements. Domain requirements are also discovered at this stage.
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 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 This multi perspective analysis is important as there is no single correct way to analyse system requirements.
Types of viewpoint •
Interactor viewpoints •
•
Indirect viewpoints •
•
People or other systems that interact directly with the system. In an ATM, the customer’s and the account database are interactor VPs.
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; g ; Sources of business and non‐functional requirements. Engineers who have to develop and maintain the system; Marketing and other business viewpoints. 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. 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. g
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 d A description of the normal flow of events; i ti f th l fl f t A description of what can go wrong; Information about other concurrent activities; A description of the state when the scenario finishes.
LIBSYS scenario (1) In it ia l assu m p ti o n : The th e c o p y o f th e a r ti cle .
u s e r h a s lo g g e d o n t o t he LI BS Y S sys te m a n d ha s lo cat e d t he jo u r na l c o n t ai n in g
N orm a l: The u s e r s e l ec t s th e a r ti cle to b e c o pi e d. He o r sh e is th e n pr o m p t e d b y th e sys te m to ei t he r p ro v i de su b sc ri be r i n f o rm at i o n f o r t he j o ur na l o r t o i n d ic a te h o w t he y w il l p ay fo r th e a r ti cle . A lte rn at i ve p ay m e n t me th o d s ar e b y c r e d it ca r d o r b y q u o ti n g an o r g a ni sa ti o n a l a c co u n t n um b e r. T h e u se r is i t he h n a sk k ed d to t fi ll in i a c o p y r ig i h t for f m th att ma in i t aii ns d eta t i ls l off th e t ra ns ac t io i n a n d th ey th e n s u bm it th is t o th e L I B S Y S sys te m . T h e c o p y ri g h t fo rm is c h ec k ed a n d , i f OK , t he P DF v e rsi o n o f t he a r tic l e is d ow nl o a d ed to th e L I B SY S w o r k i n g a r ea o n th e u se rÕs c om p u te r a n d th e u se r is i n f o rm ed th at i t is a v ai l ab l e. The u s e r is a s k e d t o se lec t a pr in t e r a n d a c o p y o f t he ar t ic l e is p r in te d . If th e a rt ic l e h a s b e en fl ag g e d a s Ōp r in t- o n ly Õ it i s d el e te d f rom th e us e r Õs sys te m o n ce t he u s e r h a s c o n f irm e d t h at p r in ti n g is c om p l ete .
LIBSYS scenario (2) W h a t c an g o w r o n g : The u s e r m a y f ai l to f il l i n t he co p y r ig h t f o rm c o rr ec t ly . I n th is ca se , th e fo rm sh o u ld b e r e- pr e s en t e d to t he u s e r f o r c o rr e c ti o n . If t he res u b m i tt ed fo rm is s ti ll in co rr ec t th en th e u se rÕs r eq u e st f o r th e a rt ic l e i s re jec t ed . T h e p a y m e n t ma y b e r ej e cte d b y t h e s y st e m . T h e us er Õs re q ue st f o r th e a rt ic l e i s re j ec t ed . T h e a r ti cle d o w n lo ad m ayy f a i l. Re t ryy u n ti l su cce ssf u l o r th e u s e r t e rm in a te s t h e s e ss io n. I t m a y n o t be p oss ib le t o p r in t t he ar t ic l e. If t h e a rt ic l e is n o t f la g g e d as Ōpr in t- o n ly Õ t he n i t is h e ld in th e L I B S Y S w o rks pa c e. O th e r w is e, t he a r tic l e is d e le t ed an d th e us e r Õs acc o u n t c r e d it ed w i th th e c os t o f th e a r ti cle . Ot h e r a c ti v i ti e s : S im u l ta n eo us d o w n l oa ds o f o th e r a r ti cle s. S y st em sta te o n c o m p le ti o n : U s e r is lo g g ed o n . T h e d o w n l oa d e d a r ti cle ha s b ee n d ele t ed fro m LI BS Y S w o r k sp ace if it h as be e n f la g g ed a s p ri nt -o n l y.
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 q g y y showing the sequence of event processing in the system.
Article printing use case 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 y y no systematic way to tackle their analysis.
Ethnography •
A social scientists spends a considerable time observing and analysing h how people actually work. l t ll k
•
People do not have to explain or articulate their work.
•
Social and organisational factors of importance may be observed 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 yp p q which focus the ethnographic analysis.
•
The problem with ethnography is that it studies existing practices which may have some historical basis which is no ti hi h h hi t i l b i hi h i 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? t ’ d ?
•
Consistency. Are there any requirements conflicts?
•
Completeness Are all functions required by the customer included? 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 •
•
Prototyping •
•
Systematic manual analysis of the requirements. Using an executable model of the system to check requirements. U i t bl d l f th t t h k i t Covered in Chapter 17.
Test‐case generation g •
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. p y g
Review checks •
Verifiability. Is the requirement realistically testable?
•
Comprehensibility. Is the requirement properly understood?
•
Traceability. Is the origin of the requirement clearly stated? y g q y
•
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 i t d i th i t i i d t 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. 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 perspective that conflict with end‐user requirements.
•
The business and technical environment of the system changes during its development. g g p
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 derived from health‐care policy
Requirements classification R e q u i rem e n t T yp e
D e s cr i p t ion
M u ta bl e r eq u ir e m e n ts
R e q u ir e m en ts th at ch a n g e b eca us e o f c ha n g e s to th e e n v i ro n me nt in w h ic h t he o rg an is at i o n is o p er a ti n g . F o r e x a m p l e, i n h os pi t al s y s tems , th e f u n d i n g o f pa t ie n t ca r e ma y c ha n ge an d t h u s re q u ir e d if fe r e n t t re at m e n t in fo r m a t io n t o b e c o l lec t ed .
E m e r ge n t r eq u ir e m e n ts
R e q u ir e m en ts th at e m e r ge a s th e c u s tom e r 's u n d e rs ta n di n g o f t he sys te m de v el o p s d u r in g t he s y s tem de v e l o p m e n t . T h e d e s ig n p r o ce ss m a y r e v ea l ne w e m e r g en t r eq u ir e m e n ts .
C o n se q u en t ia l r eq u ir e m e n ts
R e q u ir e m en ts th at res ul t f r om th e i n t r o d u ct i o n o f t he co mp u t e r s y st e m . I n t r o d u ci n g th e c o m p u te r sys te m m a y c ha n ge th e o r g an is at i o ns p ro ce ss e s a n d o p en u p n e w wa ys o f wo r k in g w h i c h ge n e r at e n e w sys te m re q u i rem en ts
C om pa t ib il it y r eq u ir e m e n ts
R e q u ir e m en ts th at de p e n d o n th e p a rt ic u la r sys te ms or b us in e ss p ro ce ss e s w it h i n a n o rg an is at i o n . As th e s e c ha n g e , th e c o mp ati b il it y r e q u i re m e n ts o n th e c omm iss io n e d o r d el i v e re d sys te m m a y a ls o h a v e t o e v o l v e .
Req irements management planning Requirements management planning •
During the requirements engineering process, you have to plan: •
Requirements identification •
•
A change management process •
•
The process followed when analysing a requirements change;
Traceability policies •
•
How requirements are individually identified;
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, th i their sources and the system design d th t d i
•
Source traceability •
•
Requirements traceability •
•
Links from requirements to stakeholders who proposed these requirements; q p p q
Links between dependent requirements;
Design traceability •
Links from the requirements to the design;
A traceability matrix Re q. R id 1 .1 1 .2 1 .3 2 .1 2 .2 2 .3 3 .1 3 .2
1 .1
1 .2
1 .3
D
R D
R
2 .1
2 .2
2 .3
3 .1
D
3 .2 D
R R R
D
D D
D R R
CASE tool support •
Requirements storage •
•
Change management •
•
Requirements should be managed in a secure, managed data store.
The process of change management is a workflow process whose stages can be p g g p g defined and information flow between these stages partially automated.
Traceability management •
Automated retrieval of the links between requirements.
Req irements change management 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 Change implementation. Modify requirements document and other documents to reflect change.
Change management
The Software Requirement Specification (SRS) Dicuplik dari buku Di lik d i b k 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. sistem software
•
Tujuan dokumen SRS tergantung dari siapa yang menulisnya. Pertama, SRS dapat ditulis oleh user , p ((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 b ft
Tujuan SRS •
Sebagai alat untuk • • •
komunikasi antar customer, user, analis dan desainer Mendukung aktivitas system testing Mengontrol evolusi dari sistem g
SRS sebagai komunikasi antar… 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 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) 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 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 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 g ( p) p p
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. Disebut tombol.
8)
Selama “powered off”, B2 dan B3 tidak mempunyai pengaruh pada kelakuan sistem.
9)
Ketika powered off, tidak ada lampu menyala.
10)
Dalam kondisi powering on, jika B2 dipijit lebih sering daripada B3, maka L1 akan menyala.
11)
Dalam kondisi powering on, jika B3 dipijit lebih sering daripada B2, maka L2 akan menyala.
12)
L1 dan L2 tidak menyala bersamaan
13)
Jika salah satu lampu rusak, lampu lain akan Jika salah satu lampu rusak lampu lain akan berkelap‐kelip secara otomatis. Kelap‐kelip berhenti ketika B4 dipijit kemudian sistem restart ketika B1 dipijit. Ketika lampu rusak diganti, lampu akan berhenti kelap‐kelip dan sistem berjalan seperti biasa.
Tombol diberi nama B1, B2, B3, dan B4. 2)
Terdapat 2 (dua) output. Disebut lampu. Lampu diberi nama L1 dan L2.
3)
B1 menjadi tombol “power on” .
4)
B4 menjadi tombol “power off” .
5)
B2 dan B3 menjadi tombol “action”
6)
Setelah B1 dipijit tetapi sebelum B4 dipijit, sistem dalam kondisi “powered on.”
7)
Sesudah B4 ditekan tetapi sebelum B1 dipijit, p sistem dalam kondisi “powered off.”
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. menjelaskan kelakuan supaya tidak ambigu
•
Perhatikan contoh di atas. ( d t (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 Teknik‐Teknik yang ada •
State‐Oriented • Finite state machine (FSM) • Statecharts • Petri nets
•
Function‐Oriented • Decision tables and decision trees D i i bl d d i i • Program design language (PDL) • Requirements Language Processor (RLP) • Specification and Description Language (SDL)
•
Object‐oriented • Statecharts • Activity Diagrams • Statechart Diagrams g
Pergi kuliah Akuntansi
[memilih akuntansi] Siap untuk kuliah
[menyadari bahwa kamu tidak suka akuntansi]
[memilih jadi programmer] Pergi kuliah IT
Pilih Karir
[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, q quality assurance plans) y p )
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 5 tahun, 10 tahun, 15 tahun dan seterusnya
•
Milestones, biaya pengembangan, dan staffing hanya selama p g pengembangan proyek g p y
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 g p p p dimasukkan dalam SRS ? •
Dua alasan utama sama dengan sebelumnya. Tidak relevan apabila D l t d b l Tid k l bil menggabungkan subjek‐subjek yang tidak berhubungan dalam dokumen yang sama dan audience untuk product assurance plan b b d d berbeda dengan audience SRS. di SRS
•
Produk assurance plan sebaiknya didokumentasi dalam S/W Quality Evaluation Plan (SQEP) the S/W Configuration Management Plan 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 Unambiguous Complete Verifiable Consistent Understandable by customer
– – – – – – –
Modifiable Traced Traceable Design independent Annotated 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 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 g User’s Needs
A
B
C
SRS 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 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 Needs
A
B
C
SRS 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 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 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 Kedua penggunaan kata‐kata yang tidak dapat diukur seperti “usually” atau “often”
Consistent (1) •
Dokumen SRS konsisten jika dan hanya jika 1)
2)
Tidak ada requirement yang tertulis di dalamnya konflik dengan dokumen sebelumnya seperti system requirements specification or a statement of work Tidak ada himpunan bagian dari requirement tertulis yang konflik
Consistent (2) Ada empat tipe dari incompleteness:
•
Conflicting behavior: Dua bagian dari SRS menspesifikasi perbedaan stimulus untuk menghasilkan responsi tertentu atau menspesifikasi perbedaan respon untuk stimulus dan kondisi yang sama sama. Contoh 1 1.
-
The light shall be lit when and only when the button is p 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 C fli ti t d i til h di k d l k t k berbeda dan mempunyai arti yang sama. Contohnya, istilah “prompt” untuk menggambarkan pesan yang ditampilkan oleh S/ u tu S/W untuk meminta pengguna memasukkan informasi. Ada juga e ta pe ggu a e asu a o as da 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,” d di t dan di tempat lain, “ t l i “ th the user command d l 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” 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, p gg , 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 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: p , 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 handset, 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, K tik d k i ik k t l i d i l di t ll SRS menyatakan: “Starting 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 Requirements, white paper, etc hi
Design Documents
S R S 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) 2)
esain ulang atau kode ulang software supaya lebih efisien i l t k d l ft l bih fi i 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 B i ti f hi ki Beri nomor setiap paragraf secara hierarki dan jangan memuat lebih dari satu requirement di dalam paragraf B i Beri nomor setiap requirement dgn nomor unik dalam kurung ti i t d ik d l k 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 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)
