Chapter 4 Questions - Identify Major Stakeholders and Constraints PDF

Chapter 4 questions – Identify Major Stakeholders and Constraints (C1.1) 1. Define a stakeholder and explain why a stakeholder is not simply someone who has a stake in a system. (pg. 113-115) o Stakeholders: Own the problem...

Chapter 4 questions – Identify Major Stakeholders and Constraints (C1.1) 1. Define a stakeholder and explain why a stakeholder is not simply someone who has a stake in a system. (pg. 113-115) o Stakeholders: Own the problem at the business operation level. Are the people from whom we elicit stakeholder needs requirements Provide necessary input during requirements analysis, such as for trade studies Should be nominated by business management o Stakeholders are not simply someone who has a stake in a system, because: The new system may affect many people, not all of whom have a right to influence the requirements 2. Briefly describe the nine tasks involved in the step "C1.1.1 Identify major stakeholders." o Identify a business owner (pg.116) Responsible for the system development. An individual or committee with sufficient authority to make decisions with regard to the project and system development. Required to negotiate between stakeholders and make the required trade-offs. o Identify all candidate stakeholders (pg. 116-117) List all actors who may, or may be perceived, to have a stake in the project. Start by identifying anyone who is affected by the outcome of the system or is able to affect it. Where possible, identify them by type. o Evaluate candidates and select stakeholders (pg. 117) Evaluate each actor, categorise as genuine stakeholder, actor or constraint. o Genuine stakeholder: Opinions on what the systems should do & perform. o Actors/constraints: we are still interested in their requirements but they are more constraints. o Understand roles and responsibilities of stakeholders (pg. 117) This information is important to guide the requirements engineering process. An essential precursor to prioritisation/categorisation of stakeholders. o Identify stakeholder representatives (pg. 117-118) Caterpillar: Non-Confidential  Identify appropriate representatives for each stakeholder, as we often can't feasibly engage with every individual of each stakeholder type. These representatives must able to speak on behalf of their relevant stakeholder community. Each representative should ideally: ▪ Understand the business domain, application area, the specific problem, systems engineering, the requirements engineering process, engineering & the associated technology. ▪ Faithfully represent the requirements of their stakeholder community. ▪ Be supportive of the new system and the requirements engineering process. ▪ Be powerful at least within their stakeholder community. ▪ Have time to contribute. o Prioritise stakeholders (pg. 118) Group stakeholders into categories. The priority and rights of each category should be explicitly defined. o Form the stakeholder board (pg. 119) Chaired by the business owner. Formed from the selected stakeholder representatives. Is the mechanism by which stakeholder needs and requirements are: ▪ Elicited ▪ Crystallised ▪ Balanced by trade-off, if necessary ▪ Endorsed ▪ Managed throughout the life of the system o Develop stakeholder management strategies (pg. 119-120) Develop strategies to maximise stakeholder involvement in requirements engineering activities. Managing stakeholders is “arguably” more important and challenging than requirements management. Stakeholder management strategies aim to ensure all stakeholders are powerful and supportive. o Prepare the stakeholder management plan (SMP) (pg. 121) The stakeholder management plan should, at least: ▪ Identify the responsible business owner. ▪ List stakeholders, by category, priority and type. ▪ Identify stakeholder representatives. Caterpillar: Non-Confidential  ▪ Identify stakeholder roles and responsibilities. ▪ Nominate the stakeholder board and identify the chair. ▪ Nominate the stakeholder management strategies (this may be in a separate document only available to business management). 3. Briefly describe the nine tasks of the chair of the stakeholder board. o The business owner is the chair of the stakeholder board, and is responsible for: (pg.116) Nominating stakeholders Allocating stakeholder rights and priorities Managing the elicitation/elaboration process Chairing the stakeholder board Arbitrating stakeholder conflict, making hard decisions where needed Providing the conduit between the business and the project Negotiates resources on behalf of the project Protects the project from the vagaries of the business environment Manages stakeholder and business expectations o There are also nine tasks involved in C1.1.1 Identify major stakeholders: (pg.115-116) Identify a business owner Identify all candidate stakeholders Evaluate candidates & select stakeholders Understand roles, responsibilities and interrelationships of stakeholders and shareholder groups. Identify stakeholder representatives Prioritise stakeholders Form the stakeholder board Develop stakeholder management strategies Prepare the stakeholder management plan (SMP) 4. Conduct the "C1.1.1 Identify major stakeholders" tasks for a space telescope project (similar to the Hubble telescope, for example) with the following stakeholders: Astronomers, Manufacturing company, National space agency, Launching company, Operating company, Politicians. 1. Identify a business owner In this case I'd assume the business owner would be the national space agency, as they would be responsible for the development of the system. 2. Identify candidate stakeholders (The list provided in the question) Astronomers Manufacturing company Caterpillar: Non-Confidential  National space agency Launching company Operating company Politicians 3. Evaluate candidates and select stakeholders Astronomers - As the primary users of the system, Astronomers would be users of the system and therefore actors. They may be considered Category 2 stakeholders, as we would engage with them to elicit their expectations of the system, some of which the National Space Agency may agree should be turned into requirements. Manufacturing company - The company manufacturing the space telescope will have limitations, based on their tooling, capability, etc. This places limitations on the development of the system, rather than specifying requirements makes them a constraint rather than a stakeholder. National space agency - The national space agency would be provided resources by the government (i.e.: politicians) in order to develop a system that allows the world's astronomers to pursue their science goals, principally improving our understanding of the universe. The national space agency is ultimately responsible for delivery of the capability and for supplying the requirements of the system - the fact they have the right to dictate system requirements makes them definitely a stakeholder. Launching company - Similarly to the manufacturing company, the launching company will have limitations (e.g.: dimensions of payload) which will influence the design of the system - this makes them a constraint. Operating company - It's assumed a company will be created to operate and maintain the system through its life. They will have finite (though yet undecided) resources which will place a constraint on the system. As the operating company will be responsible for day-to-day operation and maintenance, this also makes them users, therefore actors, and so similar to Astronomers may have expectations of the system which the National Space Agency may agree to turn into requirements. Politicians - While they will not be well placed to dictate any aspect of the design, it is important that politicians support the project as they will dictate the budget. This, combined with other constraints they may place on the project (such as dictating how the system must be acquired and any limitations on its use) make them primarily a constraint. 4. Understand roles and responsibilities, and interrelationships of stakeholders The national space agency is the only true stakeholder Astronomers and the operating company will be actors, users of the system. The manufacturing and launch company, along with politicians will be sources of constraint The interrelationships are described above. 5. Identify stakeholder representatives The head of the national space agency would delegate the project to an internal business owner/project champion - they would be the representative for the national space agency for this particular project. As for the secondary stakeholders: ▪ Astronomers - the chair of an existing, or specially assembled committee would represent the wider astronomy community with regards the expectations of the telescope Caterpillar: Non-Confidential  ▪ Politicians - similarly, the chair of a specially assembled committee would need to be created to represent the wider political community with regards to the expectations of the telescope, in particular the acquisition, and who would be allowed to use it. ▪ The operating company - would be harder, as it may not have been created yet. 6. Prioritise stakeholders The national space agency would be a Category 1 stakeholder, while astronomers and the operating company who have limited rights to set requirements would be Category 2 stakeholders. Politicians would be considered Category 3 stakeholders - as we want to ensure they feel they have some ownership over the project. 5. Briefly describe business and project constraints. (pg.127) o Business constraints include any policies, procedures, standards or guidelines set by the organisation to guide system development & procurement. o Project constraints include resources allocated to the project along with externally imposed timelines. May also include requirements to report progress in a particular way or implement certain metrics, tools or documentation procedures. 6. Briefly describe external constraints. (pg. 128) o Business environment - economic conditions. o Conformance to laws and regulations - Laws are binding within a legal construct, whereas regulations are (normally) provided by governing bodies. o Compliance with standards - Like laws and regulations, except that compliance with a standard may be at the discretion of a developer, unless it has been stipulated as required elsewhere in the requirements. o Ethical considerations and social responsibility - developers of the system have a moral and ethical responsibility to the system owners, users and community. o Interoperability and or interfacing requirements - external interfaces are often dictated by existing systems. o Operating environment - The environment the system works in will provide constraints in terms of temperature, humidity, robustness to shock, etc. 7. Briefly describe design constraints. (pg. 129) o Design constraints directly affect the way in which the system's design can be conducted. o Typically these include: state-of-the-art of relevant technologies, skillsets of available engineers/tradespeople, as well as extant (existing) methodologies and tools for the design, development, construction & production of the system. 8. Briefly explain why constraints should be tested before carrying their effects into the next activity. (pg.129- 130) o It may be tempting to accept a constraint simply because of a statement from a stakeholder, or because it has been a constraint before. Caterpillar: Non-Confidential  o Before accepting a constraint, we should always challenge it, to confirm it is really a constraint and cannot be removed. Caterpillar: Non-Confidential  Chapter 5 questions – C1.2 Define Business Needs 1. Briefly describe the four main steps in the activity C1.2 Define business needs: o C1.2.1 Develop mission, goals and objectives (pg. 139-140) Mission is drafted using a constrained bottom-up process - all important need elements are identified and used to create a draft statement Draft mission statement expressed in a single sentence Draft mission statement reviewed and iterated upon until participants are satisfied. Draft mission statement elaborated into constituent elements, which are then grouped into draft goal statements, again in an iterative fashion. Draft goal statements elaborated into constituent elements, which are then grouped into draft objective statements, again in an iterative fashion. At the conclusion, participants should be satisfied that they have completely described the system at the appropriate level of abstraction, and within their own level of understanding. o C1.2.2 Define preliminary operational scenarios (pg. 153-155) These describe the general operational environment, identifying all relevant environmental factors These depict the full range of circumstances under which the system will operate To remain efficient, do not describe every possible scenario - simply select a good set which covers all perspectives. Preliminary operational scenarios ▪ Often form the basis for test cases in acceptance testing ▪ Often describe the modes of operation for the system ▪ Should always include exception cases - what could go wrong here? ▪ Can act as a virtual prototype to help designers walk through the proposed system with users/stakeholders Preliminary operational scenarios are relatively high-level, providing only broad guidance from business management. More details are added by business operational level when the SNR are developed Preliminary operational scenarios are developed using these guidelines: ▪ First develop a general operational scenario, a "day in the life of" ▪ A method to develop a suitable, minimal set of operational scenarios is determined The perspective of each major user of the system must be covered by at least one scenario There should be as little duplication as possible Use a standard structure Use consistent language for functions and actors ▪ The set of operational scenarios are developed, including exception conditions Caterpillar: Non-Confidential  o C1.2.3 Define preliminary validation criteria (pg. 155-156) Preliminary validation criteria are how the customer will measure their satisfaction with the product of the acquisition phase, before the system is fielded (placed into operational use) Key validation criteria, or measures may include safety, reliability, supportability, maintainability, ease of use, time and cost to train. Measures can be identified using top-down or bottom-up approach. ▪ Top-down - identify high level measures, then decompose/derive lower-level measures hierarchically ▪ Bottom-up- simply list all things that are measurable without regard for their level, then analyse and group them into a hierarchy. When identifying measures, consider: ▪ Measurability - it must be quantitively or qualitatively measurable to be useful. ▪ Baseline- often the change of the measurement is more important than the exact value. Where appropriate plan to perform measurements throughout the project. ▪ Relevance- it must be related to at least one requirement o C1.2.4 Define preliminary life-cycle concepts (pg. 160-166) To ensure a focus on the full life-cycle of the system (rather than just the acquisition phase), business management must give guidance on the life-cycle concepts: ▪ Acquisition, in the preliminary acquisition concept: (pg. 162) Any business needs related to the acquisition are articulated, e.g.: budget, schedule, preferred/prohibited supply sources ▪ Deployment, in the preliminary deployment concept: (pg. 162) Business outlines the issues surrounding the deployment of the system, e.g.: arrangements for an old system to transition to a new system, or training of support personnel. ▪ Operation, in the preliminary operation concept (OpsCon): (pg.161-162) The OpsCon should contain these sections: Scope, glossary & referenced documents, Proposed system operational overview, (preliminary, at this stage) Operational scenarios, existing systems(s), nature of and justification for proposed changes, system scope. ▪ Support, in the preliminary support concept: (pg.162-163) Business management outlines the needs and related issues for the support of the system, e.g.: relevant existing support agreements. ▪ Retirement, in the preliminary retirement concept: (pg. 164-166) Identifies the reasons for potential retirement Identify potential retirement methods for the system Identify potential design issues that might arise Caterpillar: Non-Confidential  2. With the aid of a diagram, briefly describe the tasks associated with the step C1.2.1 Develop mission, goals, and objectives. C1.2.1.1: Develop mission statement - Using an iterative approach, participants develop a draft mission statement using a constrained bottom-up approach. (pg.140-144) C1.2.1.1.1: Identify candidate need elements - Participants simply list these, often in a workshop. Iterate through the list and assess whether the need element should be included, and whether anything important is missing. (pg. 140) C1.2.1.1.2: Group need elements - Aggregate need elements into 5-7 groups at a similar level of abstraction. (pg. 142) C1.2.1.1.3: Draft mission statement - Pausing with this level of understanding, the groups are then formed into a single concise sentence, with the addition of a short "in order to" clause which captures the system-level rationale. Remember that at this early stage this mission statement is not likely to be complete or correct! Footnotes/glossary can assist in capture of finer details (e.g.: what exactly is meant by "Medical Services"). (pg. 143-145) C1.2.1.2: Develop goal statements (pg. 145-147) C1.2.1.2.1: Decompose/derive goal elements- Goal elements are generated from key terms in the mission statement. Some are directly decomposed, while others are derived. (pg. 145- 146) C1.2.1.2.2: Group goal elements- Aim for roughly 7, they need to be numbered (referred to as GE1, GE2, etc.) (pg. 146) C1.2.1.2.3: Draft goal statements - iteratively draft, review and adjust goal statements (pg. 146-147) C1.2.1.2.4: Review draft mission and goal statements - review and adjust goal statements, can be good to communicate this to a wider group for review. (pg. 147) C1.2.1.3: Develop objective statements (pg. 148-151) C1.2.1.3.1: Decompose/derive objective elements - For each goal, objective elements are generated from key terms in the goal statement. Some are directly decomposed, while others are derived. (pg. 148) C1.2.1.3.2: Group objective elements - Aim for roughly 7, they need to be numbered (An example of the convention recommended is 1OE2, which means objective element 2 for goal 1). Ensure there is no redundancy or overlap! (pg. 149-150) C1.2.1.3.3: Draft objective statements - iteratively draft, review and adjust objective statements (pg. 150) C1.2.1.3.4: Review goal statements - Revisit goal statements to confirm they are balanced and complete, adjusting as needed. (pg. 150) C1.2.1.3.5: Finalise mission, goals and objectives - review and adjust mission, goal and objective statements, can be good to communicate this to a wider group for review. (pg. 150) 3. Briefly list and describe the eight desirable characteristics of a good system mission statement. (pg. 136-137) 1. Necessary - a good system mission statement makes it clear why the system is necessary 2. Singular - a good mission statement cannot be a combination of mission statements for two or more systems. 3. Correct - a good mission statement correctly identifies what is to be included Caterpillar: Non-Confidential  4. Unambiguous - a good mission statement conveys the same meaning to each reader 5. Feasible - a good mission statement is considered feasible in the judgement of the reader (a participant in the mission statement generation process) 6. Implementation independent - must describe the problem, not a solution 7. Justifiable - should end in an 'in order to' clause, explaining the rationale 8. Verifiable- it is possible to define tests to demonstrate successful system development 4. Briefly list and describe the six guidelines for the format of a good system mission statement. (pg. 138-139) 1. A single sentence - In written English, a sentence can be defined as expressing a single thought. Keeping to one sentence keeps us at the level of abstraction that defines the system as a single thought. 2. No conjunctions - Should not state the systems is to "do this, and that" as that implies there are two purposes and therefore two systems. 3. Contain no more than 5-7 concepts - keeps the statement within the intuition of the reader. 4. Includes an 'in order to' clause - makes the rationale explicit. 5. Avoids physical terms - being a good definition of a problem, using logical language. 6. Relies on iteration - A temporary lack of understanding must not be allowed to halt the design process. 5. Briefly describe the step C1.2.2 Define preliminary operational scenarios including the role and likely content of the preliminary operational concept document. (pg. 153-155) Preliminary operational scenarios are developed using these guidelines: First develop a general operational scenario, a "day in the life of" - identifying all relevant environmental factors and actors. A method to develop a suitable, minimal set of operational scenarios is determined- To remain efficient, do not describe every possible scenario - simply select a good set which covers all perspectives. The perspective of each major user of the system must be covered by at least one scenario. There should be as little duplication as possible. Use a standard structure. Use consistent language for functions and actors. ▪ The set of operational scenarios are then developed, including exception conditions. Preliminary operational scenarios are relatively high-level, providing only broad guidance from business management. More details are added by business operational level when the SNR are developed. 6. Briefly describe the step C1.2.3 Define preliminary validation criteria. (pg. 155-160) Preliminary validation criteria are how the customer will measure their satisfaction with the product of the acquisition phase, before the system is fielded (placed into operational use) Caterpillar: Non-Confidential  Key validation criteria, or measures may include safety, reliability, supportability, maintainability, ease of use, time and cost to train. Measures can be identified using top-down or bottom-up approach. ▪ Top-down - identify high level measures, then decompose/derive lower-level measures hierarchically ▪ Bottom-up - simply list all things that are measurable without regard for their level, then analyse and group them into a hierarchy. When identifying measures, consider: ▪ Measurability - it must be quantitively or qualitatively measurable to be useful. ▪ Baseline- often the change of the measurement is more important than the exact value. Where appropriate plan to perform measurements throughout the project. ▪ Relevance- it must be related to at least one requirement 7. Briefly describe the step C1.2.4 Define preliminary life-cycle concepts including the role and likely content of the preliminary life-cycle documents. (pg. 160-167) To ensure a focus on the full life-cycle of the system (rather than just the acquisition phase), business management must give guidance on the life-cycle concepts: ▪ Acquisition, in the preliminary acquisition concept: (pg. 162) Any business needs related to the acquisition are articulated, e.g.: budget, schedule, preferred/prohibited supply sources ▪ Deployment, in the preliminary deployment concept: (pg. 162) Business outlines the issues surrounding the deployment of the system, e.g.: arrangements for an old system to transition to a new system, or training of support personnel. ▪ Operation, in the preliminary operation concept (OpsCon): (pg. 161) The OpsCon should contain these sections: Scope, glossary & referenced documents, Proposed system operational overview, (preliminary, at this stage) Operational scenarios, existing systems(s), nature of and justification for proposed changes, system scope. ▪ Support, in the preliminary support concept: (pg. 162-163) Business management outlines the needs and related issues for the support of the system, e.g.: relevant existing support agreements. ▪ Retirement, in the preliminary retirement concept: (pg. 164-167) Identifies the reasons for potential retirement Identify potential retirement methods for the system Identify potential design issues that might arise Caterpillar: Non-Confidential  8. Briefly describe the three tasks designers may take into account when considering retirement aspects of the system. Identify the reasons for potential retirement: (pg. 165) There can be many reasons the proposed system may be retired, designers should first consider what these may be. For example: ▪ The system, or a critical component of the system may have reached end of life, may be unusable or unsupportable ▪ The business no longer has a need for it ▪ The business is forced to retire it due to external factors ▪ The system, or a critical component of the system may have been damaged Identify potential retirement methods for the system: (pg. 166) ▪ Designers should then examine each reason for retirement, and propose potential retirement methods for the system ▪ Some examples may be to sell the system, destroy and dispose of as waste, etc. Identify potential design issues that might arise: (pg. 166) ▪ Once retirement reasons and possible methods are identified with stakeholders, designers need to identify any design issues that may arise. ▪ Some examples may be observance of recycling regulations, cost etc. Caterpillar: Non-Confidential  Chapter 6 questions – Scope Systems and Define Business Requirements 1. Briefly describe the four main steps in the CDM activity C1.3 Scope System o C1.3.1 Develop context diagram (pg. 169-174) Context diagram illustrates the context the system exists in. Like other CDM artefacts, the context diagram can be developed bottom-up in a top-down construct. o C1.3.2 Define system boundary (pg.174) Describes which system elements are under the control of the project, and which are not. External interfaces exist at the system boundary. o C1.3.3 Define external interfaces (pg.174-181) In this step, interfaces are defined/described, their impact analysed, and the controllability analysed. A system often lives or dies by its external interfaces o C1.3.4 Endorse draft business needs (pg. 181-182) Business pauses to endorse their business needs, before the needs are converted to formal requirements. Likely undertaken as part of a major review. 2. With the aid of diagrams, illustrate what is involved in creating a context diagram for a system. (pg. 170) Caterpillar: Non-Confidential  3. Draw a context diagram for a simple system (for example, for the building of your own home). 4. Briefly discuss the issues associated with the definition of the system boundary. (pg. 174) Sometimes must be defined in logical terms, which is less straightforward than physical Can be helpful to explicitly show things outside the boundary, to show them as out of scope Feeds into the next step, defining external interfaces 5. Briefly describe the three steps associated with interface definition: interface description, interface impact analysis, and interface control analysis. (pg. 175-178) Interface description (pg. 175-176) Interface is given a name, short name and identifier Nature of interface described - who/what/when/where/why/how Interface impact analysis (pg. 176-178) Impact on the system determined Constraints identified Risk analysis conducted Interface control analysis (pg. 178) Define how (and to what extent) the interface can be controlled, so we are not trying to hit a moving target 6. Briefly describe the four attributes ascribed to each interface during interface definition. (pg. 175-176) Identifier - E1, E2, etc. for external interface 1, 2. Name- Describes unambiguously the interface (e.g.: System A - System B interface) Caterpillar: Non-Confidential  Short title- Describes the interface more briefly (omitting information that is not strictly necessary given context) Interface statement - Nature of the interface described in a single short sentence, similar to a need statement. 7. Briefly describe what is involved in interface management. (pg. 178-180) Interface documentation - relevant information captured in single safe source. External interfaces are also documented as requirements in the SyRS. Interface allocation - to a specific team, system or subsystem for implementation. Interface verification - once developed, it must be verified Interface review - of controls and impact throughout system development 8. List and briefly describe the types of external interface. (pg. 180-181) More generally, these types can apply to any type of interface: Physical interfaces - e.g.: pipes/bolts/fibre optics, defined perhaps by connection type or specification, physical size, bolt pattern/layout. Will usually coexist with other types of interfaces. Electronic interfaces - e.g.: analogue/digital signals, including RF, defined perhaps by modulation method, frequency, data format and data rate. Will coexist with physical interface definition. Electrical interfaces - e.g.: electrical power or data cable, defined by voltage, frequency (in the case of A/C or data cable), EMC requirements (shielding/earthing). Will coexist with physical interface definition. Hydraulic/pneumatic interfaces - e.g.: hydraulic/pneumatic power or data hoses/pipes, defined perhaps by flow rate, temperature, pressure, fluid type. Will coexist with physical interface definition. Software interfaces - e.g.: shared memory or internal data bus, defined by expected inputs/outputs, message format and protocols utilized. Internal data bus would coexist with a physical interface definition. Procedural interfaces - e.g.: common set of procedures and/or processes, defined by reference to SOP or process/procedure definition. Environmental interfaces - e.g.: sensor data, range of temperature, pressure, shock, radiation etc. These may be static, or dynamic - dynamic interfaces must be defined for the range of states and modes of the system. 9. Briefly describe the five main steps in the CDM activity C1.4 Define business requirements. (pg. 182-184) C1.4.1 Identify available solution classes (pg. 183) Identify system-level solution classes capable of satisfying needs Each system-level solution class may have very different stakeholder/system level requirements Aim to narrow considerations down into a useful solution space C1.4.2 Confirm compliance with business needs (pg. 183) Confirms whether, and how well each solution class achieves business needs Caterpillar: Non-Confidential  C1.4.3 Evaluate available solution classes (pg. 183-184) In terms of feasibility, performance, effectiveness, technical and project risk, etc. Concept demonstration / technical demonstration - examine existing systems C1.4.4 Select preferred solution class (pg. 184) Narrow options as much as is practicable If multiple candidate solution classes are acceptable, it may be valuable to expend effort on more exhaustive evaluation process later. C1.4.5 Define business requirements (BRS) (pg. 185) Business requirements may need to be revisited after selection of a desired solution class The hierarchical representation of business needs (the MGO) is then further elaborated into formal business requirements, forming the BRS. 10. Briefly list and describe the four main steps in the feasibility analysis undertaken in CDM (in steps C1.4.1 to C1.4.4). The four steps are, as described in the earlier answer: C1.4.1 Identify available solution classes C1.4.2 Confirm compliance with business needs C1.4.3 Evaluate available solution classes C1.4.4 Select preferred solution class C1.4.5 Define business requirements (BRS) 11. Briefly explain why the conduct of a feasibility analysis is an important activity in Conceptual Design. (pg. 182- 183) The system-level feasibility analysis is done to choose one of likely many classes of system that might meet the upper-level business requirements. This is important to ensure effort is not expended on solution classes the business does not wish to pursue. Caterpillar: Non-Confidential  12. Briefly describe the five main steps in the CDM activity C1.5 Finalise business needs and requirements (BNR). (pg. 185) C1.5.1 Revise preliminary operational scenarios Preliminary operational scenarios are revised with the selected solution class and additional understanding in mind. C1.5.2 Revise preliminary life-cycle concepts PLCDs are revised with the selected solution class and additional understanding in mind. C1.5.3 Revise system scope Mission, goals and objectives are revised with the selected solution class and additional understanding in mind. C1.5.4 Revise preliminary validation criteria Preliminary validation criteria are revised with the selected solution class and additional understanding in mind. C1.5.5 Endorse business needs and requirements (BNR) BNR are endorsed by business management - occurs likely as part of a major review. Caterpillar: Non-Confidential  Chapter 7 questions – Define Stakeholder Needs & Requirements 1. Briefly describe the five main steps in the CDM activity of C2.1 Define stakeholder needs. (pg. 187-188) o C2.1.1 Identify stakeholders Define individuals within the major stakeholder groupings defined earlier by business management Define individuals at the lower-level business operations level o C2.1.2 Refine mission goals and objectives Stakeholders at the business operation level articulate their needs by refining the MGO. o C2.1.3 Develop operational scenarios Preliminary operational scenarios outlined by business management are defined in more detail Other lower level scenarios (vignettes) are developed o C2.1.4 Develop life-cycle concepts Preliminary life-cycle concepts (PLCDs) are refined by various stakeholders to become more complete concepts, comprising the LCD (life-cycle concept documents) o C2.1.5 Endorse stakeholder needs Most likely achieved through a major review Endorsed first by stakeholders at operations level, then by business management 2. Briefly describe the four main steps in the CDM activity of C2.2 Define stakeholder requirements. C2.2.1 Identify trade studies required (pg. 188-193) Lists required trade studies Prioritises the trade studies Groups related trade studies for efficiency Allocates appropriate resources C2.2.2 Conduct trade studies (pg. 188-193) Conduct trade studies identified in earlier step C2.2.3 Define stakeholder requirements (StRS) (pg.194) Defines the StRS, sometimes called System Design Document (SDD) or stakeholder requirements, or user requirements Must be written in the language of stakeholders Must communicate completely: ▪ Likely applications or missions the system is intended for ▪ Major operational characteristics to be exhibited by the system Caterpillar: Non-Confidential  ▪ Operational constraints, which limit the design and operation of the system ▪ The external interfaces/systems the system must interface with ▪ The operational and support environment within which the system must exist ▪ The support concept, how the system will be supported Potential audience is anyone who has an interest in the delivered system, e.g.: users, operators, support personnel, system engineers and designers, test and evaluation practitioners. C2.2.4 Define validation criteria (pg. 195) Each requirement in the StRS must be accompanied by a validation statement The validation statement will show how the stakeholder will know that the system has met that requirement. These statements are used during OT&E (operational test & evaluation). Preliminary validation criteria developed earlier by business management now need to be refined into measures of effectiveness (MOE), measures of performance (MOP), verification criteria and technical performance measures (TPMs) 1. Briefly describe the four main steps in the CDM activity of C2.3 Finalise stakeholder needs and requirements (SNR). (pg. 95) C2.3.1 Revise operational scenarios Operational scenarios are reviewed with the additional stakeholder needs and decisions made as results of trade studies in mine and revised to incorporate the greater understanding. C2.3.2 Revise life cycle concepts Life-cycle concepts are reviewed with the additional stakeholder needs and decisions made as results of trade studies in mine and revised to incorporate the greater understanding. C2.3.3 Revise system scope The Mission, Goals and Objectives (MGO) plus the context diagram, system boundary and external interface are reviewed with the additional stakeholder needs and decisions made as results of trade studies in mine and revised to incorporate the greater understanding. C2.3.4 Endorse stakeholder needs and requirements (StRS) SNR are endorsed by stakeholders & business management. Likely occurs at a major review. Provides confidence to system.designers that all fundamental stakeholder requirements have been captured 4. Briefly describe the role of trade studies in scoping a system. (pg. 188-189) Stakeholders will have alternate ways of meeting their needs Ensures the decomposed/derived requirements are not too broad Design is about choices, ensure we make choices where we can to limit the scope Informed choices in design are made through trade studies. Caterpillar: Non-Confidential  5. Briefly describe the three types of trade study, identifying when each might be conducted. (pg. 189-190) Judgemental - Up to the designer. The majority are this type, chosen when consequences are not too important, one alternative is clearly superior or time is not available for a more formal approach. Formal - formally established, conducted and documented with results formally reviewed. Informal - Is of less importance to acquirer, same methodology as formal but documented less formally. 6. Briefly describe the seven steps involved in the trade study process. (pg. 190-191) A general method for conduction of a trade study: Step 1: Definition of objective and scope (pg. 190) 1. Document objective and scope in precise terms 2. Defines processes and methodologies to be used in the trade studies, including data & information collection requirements 3. Defines schedule and budget 2. Step 2: Identification of alternative solutions (pg. 190) Must identify the widest range of alternative solutions to maximise chances of selecting the optimal solution Sources include systems engineering synthesis analysis, COTS equipment, other existing equipment. Long list should be screened to remove infeasible or unsuitable solutions Remaining feasible solutions then described in sufficient detail 3. Step 3: Nomination of selection criteria (pg. 190) Formulate selection criteria that provide a measure of the effectiveness of the alternatives. Where possible these should be quantitative These should be independent (to avoid assessing some characteristics multiple times) These should be directly related to the defined problem 4. Step 4: Determination of criteria weighting (pg. 191) Weight the criteria defined in the previous step, according to their relative importance. These weightings may be withheld from those making the assessment 5. Step 5: Definition of scoring functions (pg. 191-192) Scoring functions can be linear or non-linear 6. Step 6: Evaluation of alternatives (pg. 192) Using scoring functions and criteria weighting compute a total score for each alternative Caterpillar: Non-Confidential  This will indicate the relative merit of each alternative 7. Step 7: Sensitivity study (pg. 193) Confirms the validity of the result It does this by slightly varying the scores or weights, and determining whether this effects the result. If it does, the following could be considered: ▪ Obtain additional information to further differentiate between alternatives ▪ Review criteria, weightings and scoring functions to ensure they are correct ▪ Ensure risk-management planning is in place to handle possibility that the incorrect selection is made Caterpillar: Non-Confidential  Chapter 8 questions – Define System Requirements 1. List and briefly describe the activities involved in the CDM process C3. Define system requirements. (pg.199) The aim of system requirements definition is to determine what the system must do, at the system level in order to meet the stakeholder's and businesses' needs and requirements. o C3.1 Establish systems requirements framework (pg. 200) Textbook uses RBS We start with the RBS, currently only elaborated down to level 2 (objectives) We decompose further for a more detailed logical description of the whole system o C3.2 Perform requirements analysis and allocation (pg.200-201) Elaboration of major requirements for the system with associated performance, verification and rationale statements, including operations, maintenance, support and other necessary functions. C3.2.1 Define functional/non-functional requirements (pg. 201) ▪ Identifies all required functions throughout the life-cycle of the system (e.g.: operation, maintenance, human factors). ▪ Still stated in terms of what must be done, not how to do it ▪ E.g.: functional requirements - design space limitations, environmental conditions, useability C3.2.2 Define performance requirements (pg. 204-205) ▪ It is good practice to add a performance requirement to each functional requirement ▪ This is where we decide "how well the system must do these things" ▪ Often obvious - e.g.: speed/accuracy/endurance/environmental temp ▪ Also apply to support C3.2.3 Define verification requirements (pg. 205-206) It is good practice to add a verification statement to each functional requirement Often difficult for system-level functions, but it is important Makes test plans easier to write Often a letter is attached after each functional requirement to show the proposed verification method [A] = Analysis of data, using simulation or modelling [D] = Demonstration, operation of a system or element under defined conditions to show the requirement is met [I] = Inspection, visual inspection, normally used to verify physical design features Caterpillar: Non-Confidential  [T] Test, application of a scientific method to obtain data relating to the requirement Not common in the author's experience to include these in the SyRS, rather they are included in a separate document. C3.2.4 Assign rationale (pg.206-207) ▪ Record the design decision(s), assumptions, or logic behind why the requirement exists ▪ Can be provided for each functional requirement, then inherited by associated performance and verification requirements, though sometimes it can be useful to have separate rationales for the performance and verification requirements. o C3.3 Draft system requirements specification (pg. 207-208) The populated RBS from the StRS becomes the basis for the draft SyRS Some flexibility is present at this stage to allow for subsequent design, e.g.: must/should/could. Translates the stakeholder's language into more formal specification language Requirements allocation – (pg. 207) o C3.4 Define technical performance measures (pg.209-210) TPMs are quantitative criteria, developed from the parametric requirements in preceding stages, that the system must meet. First, identify which parameters require tracking throughout the project, then prioritise them by importance to the customer. o C3.5 Conduct system requirements review (pg. 210-211) Might be done once at the end, might be done periodically. The number of SRRs and size of the review depends on the size and complexity of the system This number of SRRs should be described as part of the SEMP 2. Briefly describe the role and importance of performance requirements. (pg. 201) Performance requirements describe how well a particular functional requirement should be met. They are important because they provide more detail on the tolerances and bounds for this requirement. E.g.: functional requirement = car must be able to travel at 100 km/h, performance requirement might be that is needs to be able to travel between 99 and 101 km/h for 4 hours continuously (?) 3. Briefly describe the role and importance of verification requirements. (pg. 205) Verification requirements (note that we use ‘verification’ - have we built the system right) are given to communicate how to test that this requirement has been met. It is important as it makes test case writing much more efficient. Caterpillar: Non-Confidential  E.g.: functional requirement = car must be able to travel at 100 km/h, verification requirement might be to test a prototype. 4. Briefly describe the role and importance of assigning a rationale to each requirement. (pg. 206-207) Rationale is provided to record the design decision(s), assumptions, or logic behind why the requirement exists - this is important as it provides a number of advantages: Provides justification - forces the source to justify why the requirement should be included - 'just because' isn't enough. Picks up inappropriate expressions of a requirement - sometimes requirements are incorrectly captured as what a stakeholder thinks the system should be, not the real requirement. Improves communication - removes ambiguity, assists when more than one person is engaged in the RE effort. Enables requirements management - if the requirement must change the impact of this change can be more quickly understood 5. Briefly describe the role and use of TPMs. (pg. 209-210) The role of TPMs is to manage risks related to performance associated with system development. They are identified early and continually monitored and tracked throughout the system's development. 6. Briefly describe the role and conduct of System Requirements Reviews (SRR). (pg. 210-211) (Also CH3 pg.105) The role of the SRR is to allow requirement analysis effort to continue to lower levels, by providing a firm start point for this analysis by performing validation of the higher levels of abstraction. These reviews are conducted periodically, iteratively if you like - in line with the SEMP - in these reviews participants verify and review the various iterations of system-level requirements set. Once designers are satisfied that the set of requirements is sufficiently complete at the system level, the last review is the System Design Review (SDR). Caterpillar: Non-Confidential  Chapter 9 questions – Requirements writing 1. List the 24 guidelines for writing good requirements. (pg. 213) 1. Use a style guide (pg.214) 2. Use a standard template for a single sentence (pg.214) 3. Use a glossary to define terms (pg.215-216) 4. Use correct English expression (pg.216) 5. Use a subject appropriate to the level (pg.217) 6. Use explicit lists (pg.217) 7. Use the active rather than passive voice (pg.218) 8. Use the definite article (pg.218-219) 9. Use the same word to mean the same thing (pg.219) 10. Avoid vague words, terms & expressions (pg.220-221) 11. Avoid superfluous words (pg.221-222) 12. Avoid the use of conjunctions (pg.222-224) 13. Avoid unbounded statements (pg.224) 14. Avoid escape clauses (pg.224) 15. Use a convention for logical conditions (pg.223-224) 16. Avoid unnecessary precision (pg.225) 17. Be explicit when necessary (pg.255) 18. Use units, ranges and tolerances (pg.225-226) 19. Avoid the use of 'not' (pg.226) 20. Avoid cross-reference to other requirements (pg.227) 21. Avoid the use of pronouns (pg.227) 22. Use diagrams wherever appropriate (pg.227-228) 23. Introduce logical groups of requirements with informative statements (pg.228) 24. Ensure that each requirement is verifiable (pg.228-229) 2. Outline the generic structure of a good requirement statement and describe each of the elements. (pg. 214- 215) The generic structure of a good requirement statement is "[subject] + [priority] + [verb] + [object]" [Subject] - the entity being specified. E.g.: at system-level, this is "the system". [Priority] - generally always "shall". [Verb] - the action to be undertaken. E.g.: display, calculate. [Object] - the entity being acted upon by the subject. Optional extensions to this include [condition], appended at the beginning and [qualification], appended at the end. "[condition] + [subject] + [priority] + [verb] + [object] + [qualification]", where: Caterpillar: Non-Confidential  [Condition] - The condition under which the subject can conduct the action. [qualification] - any qualification that must be made to the action. 3. Briefly describe why requirements elements should be defined in a glossary. (pg. 215-216) o Requirements elements should be described in a glossary to ensure that a word has a precise and consistent meaning throughout the requirement set. o The glossary is also a useful place to define acronyms and abbreviations, which also will be used throughout the requirement set. 4. Briefly describe why correct English expression is required when writing requirement statements. (pg.216) o Correct English expression is required when writing requirements statements because errors or incorrect punctuation lead to ambiguity 5. Briefly describe why requirements statements should use the active rather than the passive voice. (pg. 218) o To make obvious who/what is performing the function. o Using a passive voice, it is not always clear who the subject is and it is possible to not specify a subject at all. 6. Briefly describe why requirements statements should avoid vague words, terms, and expressions. (pg.220) o To avoid ambiguity. 7. Briefly describe why requirements statements should avoid unbounded statements and escape clauses. (pg.224) o Unbounded statement provide loose bounds on the conditions under which the statement is to hold, leading to ambiguity. o Escape clauses (such as "if necessary") in an acquirer-supplier relationship give the supplier an excuse to not bother with a requirement by simply stating that, in their view, it wasn't necessary. 8. Briefly describe why requirements statements should avoid the use of conjunctions, using a formal convention for logical conditions. (pg. 222-224) o The presence of conjunctions usually means that the requirement statement should be re-written as multiple requirements. o Use of such words creates ambiguity, in English and/or can be interpreted in different ways o Where two requirements are being incorrectly stated as one, the verification statement will be different o Sometimes logical expressions of and & or are required, in which case a formal convention, using capitalised AND / OR and brackets {} should be used to remove ambiguity. Caterpillar: Non-Confidential  9. Briefly describe why requirements statements should avoid unnecessary precision but be precise when necessary. (pg. 225) o Unnecessary precision puts unnecessary burden on designers and unnecessary burden on validation o Unnecessary precision can lead to inappropriate narrowness, e.g.: exclusion of some important detail o Precision is necessary in some cases, e.g.: when it is essential that the system meet some existing constraint. 10. Briefly describe why requirements statements should avoid the use of 'not'. (pg. 226) o Presence of 'not' in a requirements statement implies 'not ever' which cannot be verified (we have finite time) 11. Briefly describe why requirements statements should avoid cross-references including pronouns. (pg. 227) o Each requirement should stand alone as a complete statement, a statement with one or more cross- references cannot stand-alone. o Pronouns are essentially a cross-reference to a noun in another statement. 12. Briefly describe the utility of introducing logical groups of requirements statements with informative statements. (pg. 228) o A large list of 'good' requirement statements alone is very difficult to read. o The addition of informative (non-binding) statements which introduce logical groups of requirements assists with the reader's understanding. 13. Briefly describe why the following are poor requirements, and rewrite them to be 'good' requirements: o The same operator shall be able to see the display from all angles. Issues: "The same operator" is a cross-reference to some other, unstated requirement (which helps it stand out here) "be able to" is redundant, superfluous. "View from all angles" is vague. Define View_Angles and Visible explicitly in a glossary. The subject and object should arguably be made specific by using a glossary (Arguably) this is expressed in the passive voice - the requirement is on the display, not the operator Proposed alternative: "The Display shall be Visible to the Operator for View_Angles < 20 degrees" o The engine temperature shall be displayed to the driver. Issues: Uses the passive voice (the subject, in this case I'm assuming the system, is entirely missing) Engine temperature is ambiguous - where is it measured, in what measurement system? Best defined in a glossary. Caterpillar: Non-Confidential  Proposed alternative: "The System shall display Engine_Temperature to the Driver" o The system shall be easy to use. Issues: "be easy to use" is vague. Define a standard Useability_Score in the glossary and specify a target. Proposed alternative: "The system shall have Useability_Score > 10" o The data shall be stored on a high-speed magnetic disk or tape drive. Issues: Use of the conjunction 'or' introduces ambiguity, if this is a true OR then use a convention for logical conditions "data" is ambiguous - define a glossary term for this Proposed alternative: "User_Data shall be stored on {high-speed magnetic disk} OR {tape drive}" o The user interface shall be flexible and user-friendly. Issues: o The use of the conjunction 'and' signifies there are multiple requirements (this expression is not singular) o "Flexible" and "user-friendly" are both not specific, vague. Proposed alternative: "The user interface shall attain Flexibility_Score of > 10", & "The user interface shall attain Useability_Score of >15" o The users shall be able to operate the system with minimal training. Issues: o "The users" is vague o "be able to" is superfluous o "minimal training" is vague, make specific o Passive voice is used here (shall be rather than shall) - the subject of the requirement is the system Proposed alternative: "The system shall be operable with < 1 hour of training" o The system shall be available 100% of the time. Issues: Unnecessarily specific, 100% availability would be impossible, provide some window of tolerance Also vague, what is meant by 'available' - define as glossary term Proposed alternative: "The system shall attain Availability_Score of > 95%" Caterpillar: Non-Confidential