I always enjoy catching up with my nephew, a biomedical engineering student at a university not too far from our home. Our family Thanksgiving dinner this year gave me an opportunity to find out how things are going for this young engineer. One of his assignments was of particular interest to me. I had just submitted a paper to The International Council on Systems Engineering (INCOSE) on the importance of incorporating cyber-security requirements at the beginning, not the end of a project. The description of his assignment made me wonder, and not for the first time, if the “requirement” element of good engineering has not somehow fallen by the wayside.
My nephew’s class was asked to design and build a centrifugal device capable of pumping blood. The assignment was given with almost no requirements! We talked about what he submitted as his device, and also about what might have been the requirements had he been working for a real-life client.
What did the pump have to be connected to? Where did the output from the pump go? What volume should the pump move? How long would the pump be required to work?
The students liked the assignment because just about anything they might imagine would fit the bill as long as the pump “pumped,” so to speak. In real life, a stakeholder would either commission the project with a list of functions/requirements for the device already prepared, or ask the engineer to create those before the project is off the ground. While I understand a first-year engineering class would start with a simple assignment, I have found that the lack of emphasis on certain engineering basics, and a realistic grounding in today’s work environment seems to be almost universal, to the detriment of many projects in both time and money.
Developing requirements is a basic function that we, as systems engineers, will always face, so I decided to call a friend of mine who is an adjunct professor of engineering at a local college to see just what in the way of requirements is being taught to the students of today. I was in luck, as he was actually in the middle of teaching a Master’s level class on requirements and offered me the name of his study guide.
This 184-page book in study guide format is called Requirements Engineering Fundamentals, by Klaus Pohl and Chris Rupp, and is the tool used to help those who will become requirements engineers pass the standards test for that particular branch of our profession. While it, too, overlooks many scenarios from real-life project situations, it is written by internationally known engineers and experts and provides a good foundation for any engineer in any choice of career.
The study guide points out the demand for understanding the sources and complexity of requirements in the 21st century. Under the chapter called Model-Based Requirements Documentation, one of my areas of interest, it gives a good overview to ready the student for the inevitable “shall statements.” These “shall statements” are the concrete promises or guarantees of just how a system will operate. They become familiar to any engineer who accepts the job of designing a project. This section in the book says, “System Requirements describe detailed functions and qualities that the system to be developed shall implement or possess.” (See page 59.)
Whether an engineer is called on to develop the requirements, or he or she comes into the work after the requirements are developed, the engineer needs to be well versed in just how they are created and derived.
What follows is my short overview on requirements taken from 30 years of experience in the field.
Any look at requirements calls for the basic question and answer found in information provided by the Institute of Electrical and Electronics Engineers: What is a requirement?
- A condition or capability needed by a user to solve a problem or achieve an objective.
- A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification or other formally imposed documents.
- A documented representation of a condition or capability as in (1) or (2). [IEEE 610.12 1990]
In addition, while covering the basics, the engineer should look at what a well-formed requirement statement is. That is:
- Can it be verified?
- Has it solved a stakeholder problem or achieved a stakeholder objective?
- Is it qualified by measurable conditions and bounded by constraints, and does it define the performance of the system when used by a specific stakeholder? [IEEE 29148 2011-12-1)
- Is the requirement clear, achievable and testable?
Finally, the “language” of requirements is important and is language I could not find in the study guide. This is what the Engineering Standard defines as the “three choices of requirements:”
“The word shall identifies mandatory provisions of this Standard. The word should identifies recommended provisions of this Standard. The word may identifies permissive provisions of this Standard.” [EIA 632 January 7, 1999]
Having established what the requirements are, now the question at hand is where do they come from?
In a real work environment, what happens frequently is that someone, a team member or peripheral member, brings in an existing document which they consider to be the source. Sometimes there are multiple team members with answers based on their experience. As you can imagine, competing sources do not create the ideal situation for the startup of a successful project.
The real question, then, is who should be involved in the development of the requirements?
The first answer is the stakeholder!
A stakeholder is: “An individual or organization having a right, share, claim, or interest in a system or in its possession of characteristics that meet their needs and expectations.” [IEEE 29148 2011-12-1]
This often means that one is presented with the task of actually discovering who the stakeholders really are, above and beyond the obvious like the system engineering team, the program manager, and the customer. To avoid for example, training, maintenance, logistics, safety, test and configuration management personnel showing up with requirements late in the process, the engineer must learn to ask the right questions. Sometimes whole groups of stakeholders find out after a review that their sections are incomplete or missing. This can lead to recurring scheduling issues for long lead time parts, a lack of study time for new safety-related issues, or equipment shortfalls for training.
Other scenarios affect requirements, too. In fact, there are a number of scenarios where unexpected requirements can erupt. Sometimes, the design team discovers that the number of requirements is much larger than originally thought, when, for example, cyber-security considerations are added in as an afterthought. Regrettably, what often happens is that managers decide that given budget constraints, they must limit teams to a fixed number of requirements. Mounting requirements can quickly add yet more requirements to other teams, quickly destroying the system design time and budget.
This points up again the critical importance of determining right at the outset who all the stakeholders are.
Implied requirements are sometimes thought to be obvious; however, they leave the developer to decide how the requirement will be delivered. Consider a project that had a requirement which called for 428 entries to be stored. The developer allowed for 428. The tester stored 430, and the system crashed in testing. Where was the requirement for the 429th entry?
Questions and strategy that a team collaborating on requirements would consider are based surprisingly on old-fashioned common sense. Here are just a few:
- Schedule structured workshops with brainstorming.
- Develop interviews, questionnaires.
- Conduct observations of the environment or work patterns.
- Review technical documentation.
- Conduct market analysis or competitive system assessments.
- Observe simulations, prototyping, and modelling.
- Document benchmarking processes and systems.
- Utilize organizational analysis techniques (e.g., Strength – Weakness – Opportunity – Threat analysis, product portfolio). [IEEE 29148 2011-12-1]
No discussion of requirements would be complete without considering the constraints. Have the constraints of the system solution been defined, and are they well stated as requirements?
The constraint element is one type of requirement which, in my opinion, is a stand-alone requirement, as it is most often overlooked.
Constraints may be imposed by:
- External or organizational stakeholder statements of need (e.g., engineering plans, technical performance measures, technical maturity, regulations, lifecycle costs, or user and operator staffing constraints)
- External, interacting, or enabling systems
- Activities from other lifecycle phases and technical activities such as transition, operation, and maintenance.
- Measures of effectiveness and suitability that reflect overall acquirer/user satisfaction (e.g., performance, safety, reliability, availability, maintainability, and workload requirements). [IEEE 29148 2011-12-1]
That brings us to the last question the engineer must ponder in his or her quest for successful completion: Do the requirements solve the problem or carry out the stated objective? If the answer is yes, the engineer is on the road to achieving the goal of a successful project.
Requirements are vitally important in understanding the development process, and this is particularly true today since the development environment may be global. Even if it is a small, local development team, communication and understanding of the problem is critical. One must have the skill to communicate enough detail to achieve the stated goal or objective.
Sadly, I didn’t get a chance to tell all of this to my nephew, but we’ll get together again for Easter. I’m already looking forward to the dinner conversation.
