TPM

OPE
REPORTS
TPM Reports
Table of Contents
1. EXECUTIVE SUMMARY.............................................................................................3
1.1 PROJECT OVERVIEW.................................................................................................................... 3
1.2 PURPOSE AND SCOPE OF THIS SPECIFICATION...................................................................................3
2. PRODUCT/SERVICE DESCRIPTION............................................................................3
2.1 PRODUCT CONTEXT.................................................................................................................... 3
2.2 USER CHARACTERISTICS............................................................................................................... 3
2.3 ASSUMPTIONS............................................................................................................................ 3
2.4 CONSTRAINTS............................................................................................................................ 3
2.5 DEPENDENCIES.......................................................................................................................... 4
3. REQUIREMENTS......................................................................................................4
3.1 FUNCTIONAL REQUIREMENTS......................................................................................................... 5
3.2 USER INTERFACE REQUIREMENTS................................................................................................... 5
3.3 USABILITY................................................................................................................................. 5
3.4 PERFORMANCE........................................................................................................................... 6
3.4.1 Capacity.......................................................................................................................... 6
3.4.2 Availability....................................................................................................................... 6
3.4.3 Latency........................................................................................................................... 6
3.5 MANAEABILITY!MAINTAINABILITY.................................................................................................. 6
3.5.1 Monitoring....................................................................................................................... 6
3.5.2 Maintenance.................................................................................................................... 6
3.5.3 Operations....................................................................................................................... 6
3.6 SYSTEM INTERFACE!INTERATION................................................................................................... "
3.6.1 Network an !arware "nter#aces...................................................................................$
3.6.2 %yste&s "nter#aces.......................................................................................................... $
3." SECURITY.................................................................................................................................. #
3.$.1 'rotection........................................................................................................................ (
3.$.2 A)t*ori+ation an A)t*entication....................................................................................(
3.# DATA MANAEMENT.................................................................................................................... #
3.$ STANDARDS COMPLIANCE............................................................................................................. #
3.1% PORTABILITY.............................................................................................................................. #
4. USER SCENARIOS/USE CASES..................................................................................9
5. DELETED OR DEFERRED REQUIREMENTS..................................................................9
6. REQUIREMENTS CONFIRMATION/STAKEHOLDER SIN!OFF.......................................1"
APPENDIX.................................................................................................................11
APPENDIX A. DEFINITIONS& ACRONYMS& AND ABBREVIATIONS.....................................................................11
APPENDIX B. REFERENCES.................................................................................................................. 11
APPENDIX C. REQUIREMENTS TRACEABILITY MATRIX.................................................................................11
APPENDIX D. ORANI'IN THE REQUIREMENTS....................................................................................... 13
TPM Reports
1. Executive Summary
1.1 Project Overview
MSB is micron's Assembly and Test Operation in Singapore.TPM OPE eports are used to evaluate
t!e Overall Production E""ectiveness #OPE$ o" t!e mac!ines in assembly.
1.2 Purpose and Scope of this Specification
T() *+,*-.) -/ 0(1. 2-3+4)50 1. 0- *,-612) -6),788 -6),61)9 -/ 0() TPM OPE
R)*-,0..
%. Product&Service 'escription
Main aim o" t!e reports is to calculate t!e overall production e""ectiveness o" eac! mac!ine in t!e
assembly. Assembly can !ave di""erent types o" mac!ines "rom di""erent manu"actures (it! di""erent
speci"ications and activities o" eac! mac!ine can be trac)ed t!roug! *EM&SE+S standards.Eac!
event&activity o" a mac!ine is mapped to *lobal Operator ,ser -nter"ace#*O,-$ system "or
standardi.ation across all t!e mac!ines and t!ese standardi.ed events are updated in database called
E,-.
TPM Reports
/rom E,-
2.1 Product Context
0o( does t!is product relate to ot!er products1 -s it independent and sel"2contained1 'oes it inter"ace
(it! a variety o" related systems1 'escribe t!ese relations!ips or use a diagram to s!o( t!e ma3or
components o" t!e larger system4 interconnections4 and external inter"aces.
2.2 User Characteristics
+reate general customer pro"iles "or eac! type o" user (!o (ill be using t!e product. Pro"iles s!ould
include5
Student&"aculty&sta""&ot!er
experience
tec!nical expertise
ot!er general c!aracteristics t!at may in"luence t!e product
TPM Reports
2.3 Assumptions
6ist any assumptions t!at a""ect t!e re7uirements4 "or example4 e7uipment availability4 user expertise4
etc. /or example4 a speci"ic operating system is assumed to be available8 i" t!e operating system is
not available4 t!e e7uirements Speci"ication (ould t!en !ave to c!ange accordingly.
2.4 Constraints
'escribe any items t!at (ill constrain t!e design options4 including
parallel operation (it! an old system
audit "unctions #audit trail4 log "iles4 etc.$
access4 management and security
criticality o" t!e application
system resource constraints #e.g.4 limits on dis) space or ot!er !ard(are limitations$
ot!er design constraints #e.g.4 design or ot!er standards4 suc! as programming language or
"rame(or)$
2. !ependencies
6ist dependencies t!at a""ect t!e re7uirements. Examples5
T!is ne( product (ill re7uire a daily do(nload o" data "rom 94
Module 9 needs to be completed be"ore t!is module can be built.
:. e7uirements
'escribe all system re7uirements in enoug! detail "or designers to design a system satis"ying t!e
re7uirements and testers to veri"y t!at t!e system satis"ies re7uirements.
Organi.e t!ese re7uirements in a (ay t!at (or)s best "or your pro3ect. See ; ; 4 Organi.ing t!e
e7uirements "or di""erent (ays to organi.e t!ese re7uirements.
'escribe every input into t!e system4 every output "rom t!e system4 and every "unction per"ormed
by t!e system in response to an input or in support o" an output. #Speci"y (!at "unctions are to be
per"ormed on (!at data to produce (!at results at (!at location "or (!om.$
Eac! re7uirement s!ould be numbered #or uni7uely identi"iable$ and prioriti.ed.
See t!e sample re7uirements in /unctional e7uirements4 and System -nter"ace&-ntegration4 as (ell
as t!ese example priority de"initions5
Priority Definitions
T!e "ollo(ing de"initions are intended as a guideline to prioriti.e re7uirements.
Priority 1 < T!e re7uirement is a =must !ave> as outlined by policy&la(
Priority % < T!e re7uirement is needed "or improved processing4 and t!e "ul"illment o" t!e
re7uirement (ill create immediate bene"its
Priority : < T!e re7uirement is a =nice to !ave> (!ic! may include ne( "unctionality
-t may be !elp"ul to p!rase t!e re7uirement in terms o" its priority4 e.g.4 ?T!e value o" t!e employee
status sent to '-S must be eit!er A or -? or ?-t would be nice i" t!e application (arned t!e user t!at
t!e expiration date (as : business days a(ay?. Anot!er approac! (ould be to group re7uirements
by priority category.
A good re7uirement is5
+orrect
,nambiguous #all statements !ave exactly one interpretation$
+omplete #(!ere TB's are absolutely necessary4 document (!y t!e in"ormation is un)no(n4
(!o is responsible "or resolution4 and t!e deadline$
TPM Reports
+onsistent
an)ed "or importance and&or stability
@eri"iable #avoid so"t descriptions li)e =(or)s (ell>4 =is user "riendly>8 use concrete terms and
speci"y measurable 7uantities$
Modi"iable #evolve t!e e7uirements Speci"ication only via a "ormal c!ange process4 preserving
a complete audit trail o" c!anges$
'oes not speci"y any particular design
Traceable #cross2re"erence (it! source documents and spa(ned documents$.
3.1 "unctiona# $e%uirements
-n t!e example belo(4 t!e re7uirement numbering !as a sc!eme 2 BA6ABCC #B "or Business
e7uirement4 6 "or 6abor elations$. /or small pro3ects simply B2CC (ould su""ice. Deep in mind
t!at i" no pre"ix is used4 t!e traceability matrix may be di""icult to create #e.g.4 no di""erentiation bet(een
'B%' as a business re7uirement vs. a test case$
T!e "ollo(ing table is an example "ormat "or re7uirements. +!oose (!atever "ormat (or)s best "or
your pro3ect.
/or Example5
Req# Requirement Comments Priority
Date
Rvwd
SME
Reviewed
!pproved
BA6ABE
T!e system s!ould associate
a supervisor indicator (it!
eac! 3ob class.
Business Process F
=Maintenance
: G&1:&B; Bob 'ylan4
Mic) Hagger
BA6ABI
T!e system s!ould !andle
any number o" "ees #existing
and ne($ associated (it!
unions.
Business Process F
=+!anging 'ues in t!e
System>
An example o" a ne( "ee is
an initiation "ee.
% G&1:&B; Bob 'ylan4
Mic) Hagger
BA6A1B
T!e system s!ould capture
and maintain 3ob class status
#i.e.4 active or inactive$
Business Process F
=Maintenance>
Some 3ob classes are old
and are no longer used.
0o(ever4 t!ey still need to
be maintained "or legal4
contract and !istorical
purposes.
% G&1:&B; Bob 'ylan4
Mic) Hagger
BA6A1J
T!e system s!ould assign t!e
Supervisor +ode based on
t!e value in t!e Hob +lass
table and additional criteria as
speci"ied by t!e clients.
April %BBE < Ke(
re7uirement. -t is one o"
t!ree ne( re7uirements
"rom BA6AB:.
%
BA6A1I
T!e system s!ould provide
t!e 6abor elations o""ice (it!
t!e ability to override t!e
system2derived Bargaining
,nit code and t!e ,nion
+ode "or to2be2determined
employee types4 including
!ourly appointments.
April %BBE < Ke(
re7uirement. -t is one o"
t!ree ne( re7uirements
"rom BA6AB;.
E&11&%BBE < Priority
c!anged "rom % to :.
%
:
TPM Reports
3.2 User &nterface $e%uirements
-n addition to "unctions re7uired4 describe t!e c!aracteristics o" eac! inter"ace bet(een t!e product and
its users #e.g.4 re7uired screen "ormats&organi.ation4 report layouts4 menu structures4 error and ot!er
messages4 or "unction )eys$.
3.3 Usa'i#it(
-nclude any speci"ic usability re7uirements4 "or example4
6earnability
T!e user documentation and !elp s!ould be complete
T!e !elp s!ould be context sensitive and explain !o( to ac!ieve common tas)s
T!e system s!ould be easy to learn
#See !ttp5&&(((.usabilitynet.org&$
3.4 Performance
Speci"y static and dynamic numerical re7uirements placed on t!e system or on !uman interaction (it!
t!e system5
Static numerical re7uirements may include t!e number o" terminals to be supported4 t!e number o"
simultaneous users to be supported4 and t!e amount and type o" in"ormation to be !andled.
'ynamic numerical re7uirements may include t!e number o" transactions and tas)s and t!e amount
o" data to be processed (it!in certain time period "or bot! normal and pea) (or)load conditions.
All o" t!ese re7uirements s!ould be stated in measurable "orm. /or example4 ?LEM o" t!e transactions
s!all be processed in less t!an 1 second? rat!er t!an =an operator s!all not !ave to (ait "or t!e
transaction to complete>.
"#$#% Capacity
-nclude measurable capacity re7uirements #e.g.4 t!e number o" simultaneous users to be supported4
t!e maximum simultaneous user load4 per2user memory re7uirements4 expected application
t!roug!put$
"#$#& !vailability
-nclude speci"ic and measurable re7uirements "or5
0ours o" operation
6evel o" availability re7uired
+overage "or geograp!ic areas
-mpact o" do(ntime on users and business operations
-mpact o" sc!eduled and unsc!eduled maintenance on uptime and maintenance communications
procedures
reliability #e.g.4 acceptable mean time bet(een "ailures #MTB/$4 or t!e maximum permitted number
o" "ailures per !our$.
"#$#" 'atency
-nclude explicit latency re7uirements4 e.g.4 t!e maximum acceptable time #or average time$ "or a service
re7uest.
3. )ana*ea'i#it(+)aintaina'i#it(
"#(#% Monitorin)
-nclude any re7uirements "or product or service !ealt! monitoring4 "ailure conditions4 error detection4
logging4 and correction.
TPM Reports
"#(#& Maintenance
Speci"y attributes o" t!e system t!at relate to ease o" maintenance. T!ese re7uirements may relate to
modularity4 complexity4 or inter"ace design. e7uirements s!ould not be placed !ere simply because
t!ey are t!oug!t to be good design practices.
"#(#" Operations
Speci"y any normal and special operations re7uired by t!e user4 including5
periods o" interactive operations and periods o" unattended operations
data processing support "unctions
bac)up and recovery operations
sa"ety considerations and re7uirements
disaster recovery and business resumption
3., S(stem &nterface+&nte*ration
Speci"y t!e use o" ot!er re7uired products #e.g.4 a database or operating system$4 and inter"aces (it!
ot!er systems #e.g.4 ,N0ires pac)age inter"aces (it! Pub+oo)ie and O'S4 0EPPS system inter"aces
(it! Budget system$. /or eac! inter"ace4 de"ine t!e inter"ace in terms o" message "ormat and content.
/or (ell2documented inter"aces4 simply provide a re"erence to t!e documentation.
Outline eac! inter"ace bet(een t!e product and t!e !ard(are or net(or) components o" t!e system.
T!is includes con"iguration c!aracteristics #e.g.4 number o" ports4 instruction sets$4 (!at devices are to
be supported4 and protocols #e.g.4 signal !ands!a)e protocols$.
"#*#% +etwor, and -ardware .nterfaces
Speci"y t!e logical c!aracteristics o" eac! inter"ace bet(een t!e product and t!e !ard(are or net(or)
components o" t!e system. T!is includes con"iguration c!aracteristics #e.g.4 number o" ports4 instruction
sets$4 (!at devices are to be supported4 and protocols #e.g.4 signal !ands!a)e protocols$.
"#*#& Systems .nterfaces
Example systems inter"ace re7uirements5
A. System1-to-System2 Interface
T!e Oexternal partyP (ill create and send a "ixed lengt! text "ile as an email attac!ment to
System%mailQu.(as!ington.edu to be imported into t!e System% system "or payroll calculation. T!is "ile
must be received on E'-T day by ;5BB PM in order to be processed in t!e E'-T nig!t run. T!e
re7uirements belo( document t!e "ile speci"ications4 data trans"er process4 and speci"ic sc!edule. T!is
"ile is re"erred to as ?/ileKame? in t!is document.
"i#e Structure and "ormat
A.1. T!e /ileKame "ile is a "ixed lengt! text "ile.
A.%. T!e /ileKame "ile is an un"ormatted AS+-- "ile #text2only$.
A.:. T!e /ileKame "ile contains a batc! totals record and several detail records.
"i#e !escription- .atch /ota#s $ecord
A.;. T!e batc! totals record can be placed at t!e beginning4 in t!e middle4 or at t!e end o" t!e "ile.
A.E. T!e batc! totals record contains t!e "ollo(ing5
1. ecord Type #value5 9A$
%. Process Type #value5 A$
:. Batc! Kumber #: digit number assigned by Payroll 'ept$
;. Origin +ode #A-*$
E. Total number o" detail records
J. Total deduction amount
TPM Reports
"i#e !escription- !etai# $ecords
A.J. T!e /ileKame "ile contains a ro( "or eac! record meeting xxx criteria.
A.G. Eac! ro( in t!e /ileKame "ile contains t!e "ollo(ing "ields4 comma2delimited and encased in double2
7uotes (!ere t!e data includes commas or spaces5
Employee -d
ecord Type
Process 'ate #MM''RR$
9R* Kumber
Element +ode
Amount
Amount Sign
Rear /lag
Total Amount
Total Amt Sign
3.0 Securit(
"#/#% Protection
Speci"y t!e "actors t!at (ill protect t!e system "rom malicious or accidental access4 modi"ication4
disclosure4 destruction4 or misuse. /or example5
encryption
activity logging4 !istorical data sets
restrictions on intermodule communications
data integrity c!ec)s
"#/#& !ut0ori1ation and !ut0entication
Speci"y t!e Aut!ori.ation and Aut!entication "actors. +onsider using standard tools suc! as Pub+oo)ie.
3.1 !ata )ana*ement
Speci"y t!e re7uirements "or any in"ormation t!at is to be placed into a database4 including
types o" in"ormation used by various "unctions
"re7uency o" use
data access rules
data entities and relations!ips
integrity constraints
data retention
valid range4 accuracy4 and&or tolerance
units o" measure
data "ormats
de"ault or initial values
3.2 Standards Comp#iance
Speci"y t!e re7uirements derived "rom existing standards4 policies4 regulations4 or la(s #e.g.4 report
"ormat4 data naming4 accounting procedures4 audit tracing$. /or example4 t!is could speci"y t!e
re7uirement "or so"t(are to trace processing activity. Suc! traces are needed "or some applications to
meet minimum regulatory or "inancial standards. An audit trace re7uirement may4 "or example4 state
t!at all c!anges to a payroll database must be recorded in a trace "ile (it! be"ore and a"ter values.
TPM Reports
3.13 Porta'i#it(
-" portability is a re7uirement4 speci"y attributes o" t!e system t!at relate to t!e ease o" porting t!e
system to ot!er !ost mac!ines and&or operating systems. /or example4
Percentage o" components (it! !ost2dependent code8
Percentage o" code t!at is !ost dependent8
,se o" a proven portable language8
,se o" a particular compiler or language subset8
,se o" a particular operating system8
T!e need "or environment2independence 2 t!e product must operate t!e same regardless o"
operating systems4 net(or)s4 development or production environments.
;. ,ser Scenarios&,se +ases
Provide a summary o" t!e ma3or "unctions t!at t!e product (ill per"orm. Organi.e t!e "unctions to be
understandable to t!e customer or a "irst time reader. -nclude use cases and business scenarios4 or
provide a lin) to a separate document #or documents$. A business scenario5
'escribes a signi"icant business need
-denti"ies4 documents4 and ran)s t!e problem t!at is driving t!e scenario
'escribes t!e business and tec!nical environment t!at (ill resolve t!e problem
States t!e desired ob3ectives
S!o(s t!e =Actors> and (!ere t!ey "it in t!e business model
-s speci"ic4 and measurable4 and uses clear metrics "or success
E. 'eleted or 'e"erred e7uirements
-denti"y any re7uirements t!at !ave been deleted a"ter approval or t!at may be delayed until "uture
versions o" t!e system. /or example5
Req#
2usiness
Requirement
Status Comments Pri
Date
Rvwd
SME
Reviewed
!pproved
BA6AB1
T!e system s!ould
validate t!e relations!ip
bet(een Bargaining
,nit&6ocation and Hob
+lass.
April %BBE5
'eleted.
T!is re7uirement
!as been replaced
by BA6AB:J and
BA++A::.
Business Process F
=Assigning a
Bargaining ,nit to an
Appointment>
1 G&1:&B; Bob 'ylan4
Mic) Hagger
BA6AB%
T!e system s!ould
validate t!at t!e
supervisor indicator is
correct according to 3ob
class.
'e"erred to P!ase %B5
:&%L&%BBE
April %BBE5
'e"erred to P!ase
%B.
Business Process F
=Assigning a
Bargaining ,nit to an
Appointment>
: G&1:&B; Bob 'ylan4
Mic) Hagger
TPM Reports
BA6AB:
T!e system s!ould
derive t!e bargaining
unit code4 union code4
and supervisor
indicator "rom t!e 3ob
class code and
location.
April %BBE5 'eleted
eplaced by
BA6A1J and
BA6A1G.
Business Process F
=Assigning a
Bargaining ,nit to an
Appointment>8 T!is
(ill eliminate t!e
need4 typically4 "or t!e
user to enter t!e
bargaining unit code4
union code and
supervisor indicator.
1 G&1:&B; Bob 'ylan4
Mic) Hagger
TPM Reports
J. e7uirements +on"irmation&Sta)e!older sign2o""
-nclude documentation o" t!e approval or con"irmation o" t!e re7uirements !ere. /or example5
Meetin) Date !ttendees 3name and role4 Comments
G&1:&BG Bob 'ylan4 6abor elations SME
Mic) Hagger4 6abor elations SME
ingo Starr4 Tec!nical Pro3ect Manager
'ebbie 0arry4 Tec!nical Analyst
Hanis Hoplin4 Tec!nical Analyst
/red Meyer4 Pro3ect Manager
+on"irmed BA6AB1 < BA6A1E
B;&1E&BE Bob 'ylan4 6abor elations SME
Mic) Hagger4 6abor elations SME
ingo Starr4 Tec!nical Pro3ect Manager
'e"erred & 'eleted5 BA6AB1 2 BA6AB;4
BA6ABG4 BA6A1%4 BA6A1;4
BA6A1E4 BA6ABJ4 BA6A1G
TPM Reports
APPEK'-9
T!e appendixes are not al(ays considered part o" t!e actual e7uirements Speci"ication and are not
al(ays necessary. T!ey may include
Sample input&output "ormats4 descriptions o" cost analysis studies4 or results o" user surveys8
Supporting or bac)ground in"ormation t!at can !elp t!e readers o" t!e e7uirements Speci"ication8
A description o" t!e problems to be solved by t!e system8
Special pac)aging instructions "or t!e code and t!e media to meet security4 export4 initial loading4 or
ot!er re7uirements.
N!en appendixes are included4 t!e e7uirements Speci"ication s!ould explicitly state (!et!er or not
t!e appendixes are to be considered part o" t!e re7uirements.
%# Definitions5 !cronyms5 and !bbreviations
'e"ine all terms4 acronyms4 and abbreviations used in t!is document.
&# References
6ist all t!e documents and ot!er materials re"erenced in t!is document.
"# Requirements Traceability Matri6
T!e "ollo(ing trace matrix examples s!o( one possible use o" naming standards "or deliverables
#/unctionalArea2'ocType2KK$. T!e number !as no ot!er meaning t!an to )eep t!e documents uni7ue.
/or example4 t!e Bargaining ,nit Assignment Process /lo( (ould be B,A2P/2B1.
/or example #1$5
2usiness Requirement !rea Deliverables Status
BA6AB1
T!e system s!ould validate t!e relations!ip
bet(een Bargaining ,nit&6ocation and Hob
+lass.222+omments5 Business Process F
?Assigning a Bargaining ,nit to an
Appointment? #Priority 1$
B,A B,A2+'2B1
Assign B, +onceptual 'esign
Accepted
B,A2P/2B1
'erive Bargaining ,nit2Process
/lo( 'iagram
Accepted
B,A2P/2B1
'erive Bargaining ,nit2Process
/lo( 'iagram
Accepted
BA6ABL
T!e system s!ould provide t!e capability "or
t!e 6abor elations O""ice to maintain t!e
3ob class&union relations!ip.222+omments5
Business Process F ?Maintenance? #Priority
1$
B,A B,A2+'2B1
Assign B, +onceptual 'esign
Accepted
B,A2P/2B%
B, Assignment ules Maint
Process /lo( 'iagram
eady/orevie(
/or example #%$5
2i1Req.D Pri
Ma7or
!rea
DevTst.tems
Deliv.D
Deliv +ame Status
BA6AB1 1 B,A B,A2+'2B1 Assign B, +onceptual 'esign Accepted
BA6AB1 1 B,A B,A2'S2B% Bargaining ,nit Assignment 'B Modi"ication
'escription
Accepted
BA6AB1 1 B,A B,A2P/2B1 'erive Bargaining ,nit2Process /lo( 'iagram Accepted
TPM Reports
2i1Req.D Pri
Ma7or
!rea
DevTst.tems
Deliv.D
Deliv +ame Status
BA6AB1 1 B,A B,A2,+'2B1 B, Assign 6 ,se+ase 'iagram eady/orevie(
BA6AB1 1 B,A B,A2,+T2BB1 B, Assignment by P+ ,se+ase 2 Add
Appointment and 'erive ,B,
evie(ed
BA6AB1 1 B,A B,A2,+T2BB% B, Assignment by P+ ,se+ase 2 Add
Appointment #,B, Kot /ound$
evie(ed
BA6AB1 1 B,A B,A2,+T2BBJ B, Assignment by P+ ,se+ase 2 Modi"y
Appointment #emoved ,B,$
evie(ed
BA6ABL 1 B,A B,A2+'2B1 Assign B, +onceptual 'esign Accepted
BA6ABL 1 B,A B,A2'S2B% Bargaining ,nit Assignment 'B Modi"ication
'escription
Accepted
BA6ABL 1 B,A B,A2P/2B% B, Assignment ules Maint Process /lo( 'iagramAccepted
BA6ABL 1 B,A B,A2,+'2B: B, Assign ules Maint ,se+ase 'iagram evie(ed
BA6ABL 1 B,A B,A2,+T2B;E B, Assignment ules Maint5 Success"ully Add Ke(
Assignment ule
evie(ed
BA6ABL 1 B,A B,A2,+T2BE1 B, Assignment ules Maint,se+ase5 Modi"y ule evie(ed
BA6ABL 1 B,A B,A2,+T2BE: B, Assignment ules Maint,se+ase 2 evie(
Assignment ules
evie(ed
BA6ABL 1 B,A B,A2,+T2BEG B, Assignment ules Maint,se+ase5 -nactivate
6ast ule "or a B,
evie(ed
BA6ABL 1 B,A B,A2,-2B% B, Assignules Maint ,- Moc)ups eady/orevie(
BA6ABL 1 B,A B,A2T+2B%1 B, Assignment ules Maint Test+ase5 Add Ke(
ule #Associated Hob +lass 'oes Kot Exist$ 2
Success
eady/orevie(
BA6ABL 1 B,A B,A2T+2B%G B, Assignment ules Maint Test+ase5 Modi"y ule
2 Success
eady/orevie(
BA6ABL 1 B,A B,A2T+2B:E B, Assignment ules Maint Test+ase5 Add Ke(
ule #Associated Hob +lass 'oes Kot Exist$ 2 Error
+ondition
eady/orevie(
BA6ABL 1 B,A B,A2T+2B;L B, Assignment ules Maint Test+ase5 Modi"y ule
2 Error +ondition
eady/orevie(
/or example #:$5
2i1Req.D CD8% CD8& CD8" CD8$ 9.8% 9.8& 9CT8% 9CT8& 9CT8" TC8% TC8& TC8" TC8$
BA6AB1
X X X X X
BA6ABL
X X X X X X
BA6A1B
X X X X
BA6A11
X
TPM Reports
$# Or)ani1in) t0e Requirements
T!is section is "or in"ormation only as an aid in preparing t!e re7uirements document.
'etailed re7uirements tend to be extensive. *ive care"ul consideration to your organi.ation sc!eme.
Some examples o" organi.ation sc!emes are described belo(5
2y System Mode
Some systems be!ave 7uite di""erently depending on t!e mode o" operation. /or example4 a control
system may !ave di""erent sets o" "unctions depending on its mode5 training4 normal4 or emergency.
2y 9ser Class
Some systems provide di""erent sets o" "unctions to di""erent classes o" users. /or example4 an elevator
control system presents di""erent capabilities to passengers4 maintenance (or)ers4 and "ire "ig!ters.
2y Ob7ects
Ob3ects are real2(orld entities t!at !ave a counterpart (it!in t!e system. /or example4 in a patient
monitoring system4 ob3ects include patients4 sensors4 nurses4 rooms4 p!ysicians4 medicines4 etc.
Associated (it! eac! ob3ect is a set o" attributes #o" t!at ob3ect$ and "unctions #per"ormed by t!at
ob3ect$. T!ese "unctions are also called services4 met!ods4 or processes. Kote t!at sets o" ob3ects may
s!are attributes and services. T!ese are grouped toget!er as classes.
2y :eature
A "eature is an externally desired service by t!e system t!at may re7uire a se7uence o" inputs to a""ect
t!e desired result. /or example4 in a telep!one system4 "eatures include local call4 call "or(arding4 and
con"erence call. Eac! "eature is generally described in a se7uence o" stimulus2response pairs4 and may
include validity c!ec)s on inputs4 exact se7uencing o" operations4 responses to abnormal situations4
including error !andling and recovery4 e""ects o" parameters4 relations!ips o" inputs to outputs4 including
input&output se7uences and "ormulas "or input to output.
2y Stimulus
Some systems can be best organi.ed by describing t!eir "unctions in terms o" stimuli. /or example4 t!e
"unctions o" an automatic aircra"t landing system may be organi.ed into sections "or loss o" po(er4 (ind
s!ear4 sudden c!ange in roll4 vertical velocity excessive4 etc.
2y Response
Some systems can be best organi.ed by describing all t!e "unctions in support o" t!e generation o" a
response. /or example4 t!e "unctions o" a personnel system may be organi.ed into sections
corresponding to all "unctions associated (it! generating payc!ec)s4 all "unctions associated (it!
generating a current list o" employees4 etc.
2y :unctional -ierarc0y
N!en none o" t!e above organi.ational sc!emes prove !elp"ul4 t!e overall "unctionality can be
organi.ed into a !ierarc!y o" "unctions organi.ed by common inputs4 common outputs4 or common
internal data access. 'ata "lo( diagrams and data dictionaries can be used to s!o( t!e relations!ips
bet(een and among t!e "unctions and data.
!dditional Comments
N!enever a ne( e7uirements Speci"ication is contemplated4 more t!an one o" t!e organi.ational
tec!ni7ues given above may be appropriate. -n suc! cases4 organi.e t!e speci"ic re7uirements "or
multiple !ierarc!ies tailored to t!e speci"ic needs o" t!e system under speci"ication.
T!ere are many notations4 met!ods4 and automated support tools available to aid in t!e documentation
o" re7uirements. /or t!e most part4 t!eir use"ulness is a "unction o" organi.ation. /or example4 (!en
organi.ing by mode4 "inite state mac!ines or state c!arts may prove !elp"ul8 (!en organi.ing by ob3ect4
ob3ect2oriented analysis may prove !elp"ul8 (!en organi.ing by "eature4 stimulus2response se7uences
may prove !elp"ul8 and (!en organi.ing by "unctional !ierarc!y4 data "lo( diagrams and data
dictionaries may prove !elp"ul.
TPM Reports