Eliciting and establishing requirements for high-tech systems from various stakeholders—each with their own wildly different perceptions of the product to be built—is challenging at the best of times. When working with hardware, software and system engineers who have different roles, backgrounds, vocabularies and technical partisanships the task can be especially demanding.
We can build anything; but the problem is knowing exactly what to build. Understanding the real needs for the product—in other words getting the right requirements—is crucial if you are to avoid market misfires, expensive recalls and reworks, or even downright failure.
This is the role of requirements co-engineering—bringing together the engineers from different disciplines to ensure that they all have the same perception of the product to be built.
This workshop brings you coherent process for discovering and writing unambiguous, testable requirements for co-engineered systems. Particular attention is paid to developing a common language for defining scope, capturing requirements, allocating them, and understanding and resolving potential conflicts that come from differing perspectives.
You Will Learn How to:
Is This for Me?
Yes, if you want to build the right product. Your title is probably systems engineer, software engineer, business analyst, systems analyst, project leader, requirements engineer, product or program manager or similar. Or if you are a user or software customer and want to ensure the requirements process delivers what you need.
What will I learn? What will I be better at?
This builds a foundation for the project by ensuring the project is viable and worthwhile. Stakeholder maps help identify the sources of requirements., which then leads to the precise scope of the area or ‘work’ to be studied and a testable goal for the project.
Here we explore techniques for partitioning the work that you need to study in order to discover the product requirements. Taking into account the technical and project constraints, further partitioning strategies show the scope of the product that you intend to build.
At the core of any requirements process is the ability to get people to tell you what they really need, rather than their perceived solution, or what they think you might be able to deliver. We show you how to employ use case workshops, interviewing, brainstorming, and other techniques to discover exactly what your customers need—and want.
Functional requirements are those things the product must do. You discover them by understanding the real tasks to be done, and determining what part of those tasks the automated product can best carry out. We show you how to use scenarios to model the tasks, and from the scenarios, how to derive the functional requirements.
Non-functional requirements are properties the product must have, such as its performance. This section also discusses qualitative non-functional requirements, such as desired look and feel, usability, and even cultural aspects.
This section demonstrates a template to help you write requirements. We also examine management issues like traceability, prioritization and conflicting requirements.
Testing is most effective when it is done early in the development cycle. The Quality Gateway rejects out-of-scope, gold-plated, non-viable, incorrect and incomplete requirements. We show how to attach an unambiguous fit criterion to a requirement to make the requirement testable and ensure the implemented solution precisely matches the customer’s expectations.
Some requirements are not discovered until the user has the opportunity to use the product. Prototyping is a way of discovering requirements by testing mock-up products for the user’s work. Here we look at the merits of both low and high-fidelity prototypes, and how they and scenarios are used to discover previously-hidden requirements.
We want you to use this right away. Each of the teaching chapters is reinforced with a workshop where you apply the concepts presented in the seminar. We use a case study that leads you from the business and system needs all the way through to requirements for individual components. Participants work in separate system and software teams to discover, specify and evaluate requirements and then they work together to complete the specification.
There's More . . .
Learning from Experience
Stephen J Mellor is an independent teacher and consultant focused on methods for the construction of real-time and embedded systems. He is the author of Structured Development for Real-Time Systems, Object Lifecycles, Executable UML, and MDA Distilled. He is also a signatory to the Agile Manifesto.
Until recently, he was Chief Scientist of the Embedded Software Division at Mentor Graphics, and founder and president of Project Technology, Inc. before its acquisition. Mr Mellor was the Chairman of the Advisory Board to IEEE Software for ten years and a two-time Guest Editor of the magazine. He is also adjunct professor at the Australian National University.
Suzanne Robertson is co-author of Mastering the Requirements Process, Second Edition (Addison-Wesley 2006) a book that provides guidance on finding requirements and writing them so that all the stakeholders can understand them. Her other requirements book, Requirements-Led Project Management (Addison-Wesley 2005) addresses how to use requirements as input to planning and management. She is also co-author of the Volere approach to requirements engineering.
She has more than 30 years experience in systems specification and building. Her courses on requirements, systems analysis, design and problem solving are well known for their innovative workshops and practical applicability. Current work includes research and consulting on finding and involving the right stakeholders, the building of requirements knowledge models and running audits for assessing requirements specifications. She is a principal and founder of The Atlantic Systems Guild and is founding editor of the Requirements column in IEEE Software magazine.
Join the Move to Better Requirements
If you want to join the elite band of software developers whose systems are used-and enthusiastically used-then come and participate when one of the industry's most respected names explains how you can get the most value from your requirements gathering activities.
It will take three days out of your schedule, and we will give them back to you with interest (think how much extensive modification and abandoned systems cost you). We know that when you use a better requirements process, you save months of maintenance effort, be more responsive to user requests, and avoid building systems that end up as shelfware.
Find out how you can gather requirements that deliver your systems earlier, and ensure that they are used, and useful.
For more information ...