Summery of Updates to this Version of the Document
\nPurpose
\nContract Summary
\nUse of the System Engineering Process
\nRequirements process
\nImportance of the Requirements Process
\nMechanisms, Methods and Tools
\nIndustry Requirements Best Practices
\nReferences consulted
\nAppendixes
\n A Requirements Process (Flowchart)
\n B Partnering Process Briefing
\n C Characteristics of Good Requirements<\/p>\n\n\n\n
\u2022 V1 This is the first version of the document. It includes a brief outline of each topic.
\n\u2022 <\/p>\n\n\n\n
{Type the summary of the contract here}
<\/p>\n\n\n\n
The system engineering process is made up of the feed back loop:
\n\u2022 The requirement loop
\n\u2022 The design loop
\n\u2022 The verification loop
\nIt is also important to consider the \u2018design ability\u2019 of the system when addressing requirements. <\/p>\n\n\n\n
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:
\u2022 Identify incorrect assumptions
\u2022 Ensure consistency
\u2022 Increase compliance
\u2022 Reduce misunderstandings
\u2022 Improve the responsiveness of suppliers
\u2022 Improve the satisfaction of all customers
\u2022 Write good requirements
\u2022 Emerge the real requirements.
<\/p>\n\n\n\n
\u2022 Establish a project team consisting of:
o Requirement engineers
o Domain experts
o A Project Champion
o Project Manager
\u2022 Capture initial requirements
\u2022 Project inception checklists taken from the project managers toolkit:
o Simple Risk Assessment.
o Twelve Project Procedures to have in place before you start
\u2022 Initial Use Case and Class Diagram with associated CRC cards
\u2022 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)
\u2022 Develop an Operational Concept Description and documentation of the rational for each requirement (OCD)
\u2022 Refine Use Case and write descriptions.
\u2022 Update class diagrams and CRC cards
\u2022 Prioritise requirements
<\/p>\n\n\n\n
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.
\n80% of all product defects are inserted at the requirements definition stage.<\/p>\n\n\n\n
\u2022 UML (Use Cases)
\n\u2022 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.
\n\u2022 Iterative development cycle
\n\u2022 Rose Rational Development Software.
\n\u2022 Work towards a quality culture.<\/p>\n\n\n\n
\u2022 UML compliance
\n\u2022 BSC requirements for certain projects<\/p>\n\n\n\n
\u2022 Effective Requirements Practices \u2013Ralph R. Young
\n\u2022 Project Managers Toolkit \u2013 David M Shailer
\n\u2022 M301 Course Material<\/p>\n\n\n\n
\u2022 Respect each person.
\u2022 Share responsibility.
\u2022 Criticize ideas, not people
\u2022 Keep an open mind
\u2022 Question and participate.
\u2022 Arrive on time
\u2022 Keep interruptions to a minimum
\u2022 Manage by fact.<\/p>\n\n\n\n
\u2022 Respect each person.
\u2022 Share responsibility.
\u2022 Criticize ideas, not people
\u2022 Keep an open mind
\u2022 Question and participate.
\u2022 Arrive on time
\u2022 Keep interruptions to a minimum
\u2022 Manage by fact.<\/p>\n\n\n\n
Criterion Description
Necessary Can the system meet prioritized, real
needs without it? If yes, the requirement
isn\u2019t 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 \u201csystem level,\u201d the \u201csegment
level,\u201d and the \u201csubsystem 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 \u201cshall.\u201d Statements indicating
\u201cgoals\u201d or using the word \u201cwill\u201d are not
imperatives.
Unique identifier Each requirement should have a unique
identifying number that assists in identification,
maintaining change history, and
providing traceability.<\/p>\n\n\n\n
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 … Continue reading REQUIREMENT PLAN DEVELOPMENT (Template)<\/span>