Mastering the Requirements Process I - Build the Right Software - 1st Time

Referent:
Suzanne Robertson

This seminar will give you:
      • A process for gathering the correct requirements
      • Methods of eliciting requirements from all the stakeholders
      • Ways of knowing when your solution precisely matches what the user needs
      • The ability to write a compete and unambiguous requirements specification
      • Improved relationships with your software customers

Is the next system you build one that the users will look back after years of happy use and thank you for... or will you look back after years of heavy maintenance and wonder why it happened to you?
 
Why Requirements – What’s in it for You?
People use software, but other people build that software. There’s the problem. Solving it means understanding the actual work of the business users, and what they need in order to do it. It does not mean finding a quick fix for a perceived problem. It does mean deducing the product that adds long-term value to the organization, and then writing requirements that lock the developers in to that exact product. Any omissions or ambiguities mean going back to step one.

Getting it Right the First Time
The days of building software in “Internet time” are over. Building software today means that you are in it for the long haul. And you know that there are more demands than ever, and fewer resources to meet those demands. Getting the software right – the first time – is the only way to succeed under these circumstances. Today’s requirements process is incremental with quick cycle times. It uses prototypes and scenarios, and it ensures that you get the right result by writing a fit criterion – a test case for the requirement.

Your Requirements
Requirements are the most misunderstood part of systems development, but also the most crucial. Get the requirements wrong and you get the wrong system. Your requirements process must be your own, but it should be based on field-proven techniques and templates. In this course, you are shown the Volere process – used and improved by thousands of organizations around the world – and how you make it your own process. You also receive the Volere Requirements Specification Template – downloaded by over 13,000 users – to take home with you along with advice on how to make this your own template.

Is This for Me?
This seminar has indispensable information for business analysts, systems mangers, project leaders, consultants and systems analysts and planners. This material applies to all stakeholders: users and customers will benefit from learning how to participate in this multi-disciplinary approach. It is for anybody who has a responsibility to deliver the right products - the ones that get used.
 
What Will I learn? What Will I be Better at?

• The Requirements Process
This section introduces you to the Volere process – a solid strategy for gathering the correct requirements. In this overview session you see how the pieces fit together – from the project blastoff that established the product’s purpose and scope, the trawling and prototyping activities that elicit the product’s requirements, through the Quality Gateway where requirements are made testable, to the final review of the specification that discovers any missing requirements.

• Project Blastoff
This activity lays the foundation for the requirements project by establishing the Scope-Goals-Stakeholder trilogy. This initiation activity establishes the precise scope of the work to be studied, determines a testable goal for the project, and uses stakeholder maps to identify all the sources of requirements. In short, the blastoff ensures that the project is viable and worthwhile.

• Trawling for Requirements
At the core of any requirements process is the ability to get people to tell you what they really need, rather than what they think you might be able to deliver, or what they feel their boss might want. We show you how to apply business use cases, use case workshops, interviewing and other strategies to discover exactly what the users need, and want.

• Functional Requirements
Functional requirements are those things that the product must do. They are discovered by inspecting the work that the user does, and then determining what part of that work the automated product can do. This proposed interaction between user and product is modeled with use case scenarios. From these, we derive and write the functional requirements.

• Non-functional Requirements
Non-functional requirements are those properties that the product must have, such as the desired look and feel, the usability, the performance and its cultural aspects. This section discusses the types of non-functional requirements, and shows you how to use the template, and other methods, to find the qualitative requirements for your product.

• Managing Your Requirements
Requirements are the lynchpin of any development effort, and as such have to be written correctly and managed effectively. This section demonstrates the use of a template and other devices to help you write requirements.  It also looks at requirements management issues like traceability, prioritization and conflicting requirements.  We also include a review of most of the automated tools that are available to help manage requirements specifications.

• The Quality Gateway
Testing is most effective when it is done early in the development cycle. In the Quality Gateway, we demonstrate how to test requirements before they are added to the Requirements Specification. This Quality Gateway rejects out-of-scope, gold-plated, non-viable and incorrect and incomplete requirements. We also demonstrate how you can attach an unambiguous fit criterion to each requirement. This makes the requirement testable, as well as ensuring that the solution you implement precisely matches the customer’s expectations.

• Prototyping and Scenarios
Some requirements are not properly understood until the user has had the opportunity to use the product. Prototyping is a way of discovering requirements by testing mock-up products for the user’s work. In this section we discuss the merits of both low and high fidelity prototypes, and how they and scenarios can be used to discover and demonstrate the requirements in action.

• Your Requirements Process
Your next requirements project is different from anybody else’s. In this section we look at how to make your own requirements process as effective and efficient as possible. We look at accelerating the requirements gathering by establishing the scope then building an early throwaway prototype. We introduce the requirements Knowledge Model as a basis for you to improve your  requirements process. Each part of the process is then examined so that participants can discuss problems and ideas related to their processes, and how they can use this to improve their existing requirements process.  

• There’s More…
• Your own copy of the acclaimed Mastering the Requirements Process by Suzanne and James Robertson published by Addison Wesley.
• A copy of the Volere Requirements Specification Template. This complete template provides a foundation for writing your own specifications.
• A survey of the tools currently available to assist requirements capture and recording.
• References to books and sources of up-to-date requirements engineering techniques
• An opportunity to discuss any requirements problems one-on-one with a requirements professional. He or she will bring several decades of experience to the conversation.

Workshops
The course includes intensive workshops that give you the opportunity to apply the concepts presented in the seminar. Participants work in teams to discover, specify and evaluate requirements for a significant system. The workshops provide practical experience in building requirements specifications by:
• Defining the project’s scope, its goals and the relevant stakeholders
• Identifying business use cases and product use cases
• Prototyping the product
• Applying the requirements specification template
• Defining functional and non-functional requirements
• Deriving the fit criterion, or measurement, for each requirement

 
Learning from Experience
Suzanne Robertson is co-author of Mastering the Requirements Process (Addison-Wesley 1999) a book that provides guidance on finding requirements and writing them so that all the stakeholders can understand them. The follow-up 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 editor of the Requirements column in IEEE Software magazine.

James Robertson is a consultant, teacher, author, project leader whose area of concern is the requirements for products, and the contribution that good requirements make to successful projects. James is a leading proponent of the principle of introducing creativity into the requirements process. His controversial article “Eureka: Why Analysts Should Invent Requirements” in IEEE Software, July 2002, has been widely quoted and discussed.

Before becoming a systems engineer, James trained as an architect and his experience in that profession provides inspiration for his work on innovation and creativity.  He is co-author of Mastering the Requirements Process (Addison-Wesley 1999), Requirements-Led Project Management (Addison-Wesley 2005) and the Volere approach to requirements engineering. He is also a principal and founder of The Atlantic Systems Guild, a think tank known for its research into new systems engineering techniques.

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 hear one of the industry’s most respected names explain how you can gather the correct requirements. 
It will take three days out of your schedule, and we will give them back to you with interest. We know that when you use a better requirements process, you will 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 have a requirements process that will deliver your systems earlier, and ensure that they are used and useful.