On May 11, 2019 we presented our 1-day Scope Definition seminar for the INCOSE ChicagoLand Chapter Spring Seminar offering to their membership. This was a natural follow on seminar to the Writing Good Requirements seminar we presented at the 2018 Spring Seminar. Feedback from the attendees indicated the seminar was very well received! One of the attendees sent us an email this week that stated:
“Thanks again for another excellent and enlightening Spring Seminar! All this week, I have been applying what I learned which has been very effective and helpful!”
We started out the seminar with a brief summary of five key insights gained from the International Council of Systems Engineering (INCOSE) Requirement Working Group (RWG) sessions I chaired at the International Workshop (IW) 2019 in Torrance, CA the end of January.
The theme of the RWG sessions was: “Requirements in a Model-based Systems Engineering (MBSE) World.” These insights are summarized below:
- The concept of “duality” as applied to requirements and models. Depending on the what is being done and what is being communicated, textual requirements and models are two sides of the same SE coin. Neither is solely sufficient – both are needed!
- Requirements don’t just happen – they are a transformation from a set of needs, that was transformed from a set of concepts that address a feasible solution to a problem.
- The quality of the requirements is directly proportional to the quality of the set of stakeholder needs from which they were transformed. Likewise, the quality of the set of needs is directly proportional to the quality and quantity of the work done to define the problem, understand the stakeholder expectations, drivers and constraints, and risks – as well as the time and effort spent in defining a feasible logical and physical concept (model) based on this information prior to documenting the needs.
- Preliminary conceptual and physical design architectural models are both the source of the stakeholder needs and resulting requirements (design inputs) as well as the tools used to implement those same sets of needs and requirements in the form of the design and the engineered system of interest (design outputs).
- 20thcentury SE methods and practices are often not adequate to address the challenges of increasingly complex, software centric systems of the 21stcentury!
From these insights, the bottom line is that if you want a good set of requirements, there is a lot of work to do first! This work involves defining the scope of the project and developing a feasible concept from which stakeholder needs are defined and then transformed into the system of interest requirements. Part of these activities involve the use of diagrams and models to help ensure the set of needs and resulting requirements are correct, complete, and consistent.
Eliciting key information and obtaining stakeholder buy-in is a must prior to defining stakeholder needs and requirements. The collection and documentation of this information is referred to as “Scope Definition”. Whether a project begins with a clean slate, begins with the receipt of a customer’s set of requirements, or upgrading an existing product, understanding the Scope of the project is essential prior to writing, reviewing, approving, managing, and implementing requirements.
Failure to address Scope prior to writing requirements is one of the major reasons for costly rework and failed projects. It is extremely difficult to write requirements and develop a winning product without a common vision. Without a documented Scope, each author will have a different vision and the resulting requirements will be inconsistent, incomplete, and incorrect. Efforts to identify defective requirements are not only time consuming, but fraught with arguments between team members who have different visions. All too often identification of requirement defects doesn’t become apparent until system integration verification and validation, resulting in costly rework, and failed projects.
Learning how to gather and document project and product Scope is one of the most productive activities to improve the quality of requirements and project success. Information documented in the Scope definition phase supports the design, verification, validation efforts and can reduce cost overruns and schedule slips by 30% or more from start to finish.
After discussing the above five insights, the rest of the seminar focused on the following key activities that are part of scope definition:
- Defining the problem
- Defining Need, Goals, Objectives
- Identifying stakeholders
- Eliciting stakeholder expectations
- Defining risks, drivers, and constraints
- Developing and maturing a feasible concept
- Documenting stakeholder needs
- Baselining Scope.
To illustrate the outcomes of each of these activities, a “Candle Lighting Robot” case study was used.
The following figure shows how all these activities are related, specifically the information and knowledge needed to mature a concept from which a set of needs are defined and transformed into the system technical requirements.
To learn more about this seminar and other seminars offered by Requirements Experts you can click here.
From a Business Analysis, Agile approach to the development of software applications, you can visit the Seilevel website by clicking here.Tags: Drivers and Constraints, feasible concept, Need goals objectives, Need statement, needs, risks, Scope Definition, stakeholder expectation, stakeholder needs, system concept