System Requirements and Functions

Abstract

Vast majority of system failures can be attributed to us, developers, not knowing what the system should do and how specifically some functions need to be performed. The field of requirements engineering is, unfortunately, neglected in many projects, and the requirements are looked at as being “the necessary evil” and the afterthought in the sense of filling up paperwork for audits. In this chapter, we would demystify the role of requirements and the high-level system specification and how it shall be done properly. We would emphasize the selection of stakeholders for the requirement elicitation process and further prioritization and expression of the requirements. Understanding the importance of the requirements is essential to pinpoint the very origins of system safety and how the safety can start to be regarded inherently.

Appendices

Exercise 2

For the electric scooter with geofencing, discussed in Chapter 1, now we need to construct a brief system requirements specification (on the functional level). In the first part of the exercise (20 min), your team shall construct a requirements specification of at least ten requirements, denoting the requirements that present system functions (functional requirements), and other requirements related to constraints (safety!) or quality. In the second part of the exercise (10 min), the requirements shall be reviewed with the stakeholders, which are from your counterpart team, using the Kano model. In the last 10 min of the exercise, your team shall prioritize the requirements according to the outputs of the Kano analysis (Fig. 2.6).

Fig. 2.6

System requirements specification after Kano analysis (prioritized)

Your Tasks for the Exercise

• Based on the discussion from Chap. 1, now fill in the requirements table correctly. To show traceability, consider some high-level requirements but do not spend time writing them in. Also, use dummy technical requirements for reference at this point.

• Mark all functional requirements with the prefix FR, quality with QR, constraint with CT, and safety with SF.

• Make sure to follow the formulation wording correctly (e.g., “The system shall …”) making sure to be clear, nonambiguous, and complete as much as possible.

• Present the table to the counterpart group. Split all requirements into the categories (Delighter, Performance, Must Have, Questionable, Indifferent or Reverse) according to the Kano analysis, and prioritize (Performance, then Delighters, then Indifferent) and remove Reverse ones.

• What about the completeness of the stakeholder list? Can you actually remove some requirements based on any stakeholder response? Get ready to discuss!

To-Do List

• Perform the exercise individually or with your peers. One can share the screen and keep notes, all contribute.

• Create presentables (e.g., drawing, Excel calculation).

• Discuss your solution and share with others.

Note: Digital files for this exercise are available at sfs2.ex.nit-institute.com

Exercise 2 Template

Exercise 2 Sample Solutions

See several exemplary solutions to the exercise:

Solution 1

Review Comments by the Instructor

• FR_007 seems more like a technical requirement than a functional requirement. Functional requirements describe system functions (goals) – the system provides these functions toward their users/operators, and the effects of those functions manifest toward the environment, at the system boundary (as well as failures of those functions!). Instead, say, FR_007 might cover the need for geofencing (as in SR_001), whereas FR_007 might become TR_XXX derived from SR_001.

• Generally, when deriving functional requirements, it is good to first list the operation modes of the system (e.g., driving, parked, rolling, carrying) and then list various functions for each of the modes.

Solution 2

Review Comments by the Instructor

• Usually, functional requirements come first, stemming directly from high-level requirements. Constraint and quality requirements are very important, but in the presentation to the stakeholders, they shall be put second since they sound more technical. Generally, the requirement engineer shall act as a facilitator of the communication among the stakeholders; therefore, easy-to-understand requirements (nonambiguous, agreeable) are desired.

• Kano analysis yielded Delighter for the CR_001 which states the maximum allowed velocity of the scooter. Usually, this requirement delights safety engineers or legislators/auditors, so it is indeed possible. Please note here that depending on the stakeholders, Kano analysis may give different results, and sometimes the results must be averaged or weighted according to the importance of a stakeholder. It is in the end all about the argumentation so many approaches in prioritization and agreements are possible as long as the problem has been analyzed from various angles and among all relevant stakeholder groups.

• Make sure not to have a vague requirement definition. For example, QR_002 states “adaptable to brightness.” This is unclear. What kind of adaptation shall be provided? Instead, “display shall remain visible for all daylight brightness levels” would be more clear. Also, “change direction when steered” in FR_004 is also vague; better: “change the direction according to the position of the steering handle.”

• FR_005 is rather a safety requirement; however, it must also have additional requirements (maybe derived from it) which would specify in more detail how such a critical operation must be handled (e.g., producing an alarm, slowing down, etc.).

Solution 3

Review Comments by the Instructor

• Again, different stakeholders may respond differently to requirements (e.g., Must-Have for SF_004 could change if we are to make inquiries among children).

• SF_003 is removed after Kano; however, it is questionable whether the safety engineer was among the stakeholders (to bring additional perspective to this requirement).

• In FR_005, make sure not to use vague terms, such as “easier transport.” Better: “to enable the carrying with one hand.”

• Make sure to have variables resolved in the same document, in the definitions section, and that they are kept together with the specification so that those values cannot be arbitrarily interpreted.

Solution 4

Review Comments by the Instructor

• FR_008 is rather a technical requirement that can be derived from a functional requirement in which sound alerts may be utilized (e.g., battery low alert, etc.). Functions at the scooter level shall clearly describe the goals of the complete system toward the users/operators and with respect to the environment.

• Geofencing may be even stated as a safety goal (SG) which is defined together with high-level requirements (HLRs). Then, safety requirements (SFs) are derived from SGs, and FRs are derive from HLRs, whereas SFs are related to FRs.

• FR_007 might be made more clear if stating the connection with the use case (e.g., renting), which can be set up in the HLR from which FR_007 was derived.

• The weight limit shall be set in FR_004 or additional FR as for the configurability of this limit in, e.g., maintenance phase shall be enabled (although this is unlikely).

• QR_001 is impossible to implement as it is currently formulated.

Key Recap Questions

In this you have been reading about and practicing exemplary requirements engineering practices through requirement elicitation:

• Think about a recent system you worked with.

• Remember its requirements specification.

• Were you involved in the elicitation?

• How would YOU perform the elicitation if given the task?

• Imagine how bad (or nonexistent) requirements impact safety.

Self-assessment

Now take the time to self-assess your knowledge by taking the quiz below. Each listed statement is either correct or incorrect. Please mark your answer and then check in the key at the end of the book.

• 1. Requirement elicitation is performed among the project team members in a company develo** a system.

• 2. Social groups outside the system boundary (in the system environment) are among the stakeholders in the requirements development process.

• 3. Failing to fulfill a constraint requirement may bear the risk to system safety.

• 4. The requirement engineer is not in charge of requirements communication, coordination, and escalation.

• 5. To apply a Kano analysis, the initial requirements specification needs to be assembled as a proposal to the stakeholders.

• 6. If a stakeholder expects that a listed feature is not present in the system, but would like it to be present, then this feature is assessed to be a Delighter according to Kano analysis.

• 7. Kano analysis helps us to detect features that “go without saying” and are usually not directly stated by the stakeholders.

• 8. System requirements specification allows a hierarchical view of the requirements, allowing traceability from, e.g., the functional requirements to technical requirements, but traceability to other artifacts (design specification, items, tests) is not maintained.

• 9. Safety requirements can only be defined by assessing failures of functions implementing functional requirements.

• 10. Dangerous failures of system functions, which implement functional requirements of the system, always lead to system hazards and potential accidents; therefore, the requirements specification needs to be complete before the safety assessment.

Self-assessment Key

• 1. False

• 2. True

• 3. True

• 4. False

• 5. True

• 6. True

• 7. True

• 8. False

• 9. False

• 10. True