Contents
Summery of Updates to this Version of the Document
Purpose
Contract Summary
Use of the System Engineering Process
Requirements process
Importance of the Requirements Process
Mechanisms, Methods and Tools
Industry Requirements Best Practices
References consulted
Appendixes
A Requirements Process (Flowchart)
B Partnering Process Briefing
C Characteristics of Good Requirements
Summery of Updates to this Version of the Document
• V1 This is the first version of the document. It includes a brief outline of each topic.
•
Contract Summary
{Type the summary of the contract here}
Use of the System Engineering Process
The system engineering process is made up of the feed back loop:
• The requirement loop
• The design loop
• The verification loop
It is also important to consider the ‘design ability’ of the system when addressing requirements.
Suggested Strategy
The use of a mechanism to maintain project communication is not as important as it would be in a real project. The channels of communication need in this project are:
PLEASE TYPE COMMUNICATION CHANNELS
In addition it is important to select familiar methods and maintain a set of work products. Also use a change control board to plan for changes in requirements and implement a quality function deployment policy.
The goals of a good requirement process are:
• Identify incorrect assumptions
• Ensure consistency
• Increase compliance
• Reduce misunderstandings
• Improve the responsiveness of suppliers
• Improve the satisfaction of all customers
• Write good requirements
• Emerge the real requirements.
Requirements process
• Establish a project team consisting of:
o Requirement engineers
o Domain experts
o A Project Champion
o Project Manager
• Capture initial requirements
• Project inception checklists taken from the project managers toolkit:
o Simple Risk Assessment.
o Twelve Project Procedures to have in place before you start
• Initial Use Case and Class Diagram with associated CRC cards
• Carry out a detailed elicitation of requirements using activity diagrams etc. avoiding
o Gold plating and training engineers not to gold plate but to make requirement decisions.
o Peripheral requirements.
o Flag unverifiable requirements (please see verification plan)
• Develop an Operational Concept Description and documentation of the rational for each requirement (OCD)
• Refine Use Case and write descriptions.
• Update class diagrams and CRC cards
• Prioritise requirements
Importance of the Requirements Process
The requirements process is important because if an important requirement is miss-interpreted of even missed the greater the risk to the project as a whole. The cost of such errors increases the later they are found. Therefore the more detailed the requirements process is the likelihood of such errors being found is greatly reduced.
80% of all product defects are inserted at the requirements definition stage.
Mechanisms, Methods and Tools
• UML (Use Cases)
• Techniques that can be used to elicit requirements includeing: interviewing, questionnaires, workshops, brainstorming, idea reduction, story boards, use cases, role play and prototyping. Prototyping is not planned to be used due to the lack of experience in programming. Another technique not being used will interviewing, questionnaires and workshops. There may be difficulty contacting and engaging people in the card industry and so I do not think it would be a good use of my time in engaging in such activities. If this was a real project these would be valid and useful to any development project.
• Iterative development cycle
• Rose Rational Development Software.
• Work towards a quality culture.
Industry Requirements Best Practices
• UML compliance
• BSC requirements for certain projects
References
• Effective Requirements Practices –Ralph R. Young
• Project Managers Toolkit – David M Shailer
• M301 Course Material
Appenixes
A REQUIREMENT PROCESS (FLOWCHARTS AND PROCESS DESCRIPTIONS)
B PRC RULES OF CONDUCT
• Respect each person.
• Share responsibility.
• Criticize ideas, not people
• Keep an open mind
• Question and participate.
• Arrive on time
• Keep interruptions to a minimum
• Manage by fact.
C PRC RULES OF CONDUCT
• Respect each person.
• Share responsibility.
• Criticize ideas, not people
• Keep an open mind
• Question and participate.
• Arrive on time
• Keep interruptions to a minimum
• Manage by fact.
D CRITERIA OF A GOOD REQUIREMENT
Criterion Description
Necessary Can the system meet prioritized, real
needs without it? If yes, the requirement
isn’t necessary.
Verifiable Can one ensure that the requirement is
met in the system? If not, the requirement
should be removed or revised. Note: The
verification method and level at which the
requirement can be verified should be
determined explicitly as part of the development
for each of the requirements. (The
verification level is the location in the
system where the requirement is met (for
example, the “system level,” the “segment
level,” and the “subsystem level).1
Attainable Can the requirement be met in the system under development?
Unambiguous Can the requirement be interpreted in
more than one way? If yes, the requirement
should be clarified or removed. Ambiguous or poorly worded writing can lead to serious misunderstandings and needless rework. Note: Specifications
should include a list of acronyms and a
glossary of terms to improve clarity.
Complete Are all conditions under which the
requirement applies stated? Also, does
the specification document all known
requirements? (Requirements are typically
classified as functional, performance,
interface, constraints, and environment.)
Consistent Can the requirement be met without
conflicting with all other requirements? If
not, the requirement should be revised or
removed.
Traceable Is the origin (source) of the requirement
known, and can the requirement be referenced
(located) throughout the system?
The automated requirements tool should
enable finding the location in the system
where each requirement is met.
Allocated Can the requirement be allocated to an
element of the system design where it can
be implemented? If not, the requirement
needs to be revised or eliminated.2
Concise Is the requirement stated simply and
clearly?
Implementation free The requirement should state what must
be done without indicating how. The
treatment of interface requirements is
generally an exception.
Standard constructs Requirements are stated as imperative
needs using “shall.” Statements indicating
“goals” or using the word “will” are not
imperatives.
Unique identifier Each requirement should have a unique
identifying number that assists in identification,
maintaining change history, and
providing traceability.
- See Grady, System Validation and Verification, pp. 101–102, for a discussion of verification levels.
- The alternative is to risk a major costly change in the system or software architecture.