The goal for this presentation is to provide an introduction to the types of visual requirements models that exist and show the value that they provide.**[TONY: AND SHOW YOU HOW THEY CAN BE SUPPORTED BY BLUEPRINT, A MODERN, COMPREHENSIVE PRODUCT FOR DEFINING AND MANAGING REQUIREMENTS]Then we want to give you a few hands-on examples of models you can begin using right now in your projects. We will walk through a sample project using those models in order to allow you to learn how to create them on your own.How to model business processes to define requirementsHow to model user interface screen display and behavior requirementsHow to map requirements to identify missing requirements, ensure coverage across multiple models, and cut requirements from scope**[TONY: FOR EACH OF THESE WE WILL SHOW YOU HOW YOU CAN USE BLUEPRINT TO DO THEM]
Meet Blue, the BA. Blue recently was moved to a project that had 40 use cases, all of them each 20 pages long! Wow, those must have been some serious use cases! And there were thousands of requirements listed out too. He was tasked with completing the requirements. Like most BAs, Blue has a lot of work on his plate, with lots of people telling Blue what needs to get done. But Blue is concerned that he never knows if he has actually elicited all of the requirements necessary for his projects. And diving into this one where a lot of work has already been done, he’s even more uncertain of how to know when the requirements are done. In fact, he suspects there are a lot of requirements buried in these use cases. But he’s finding the use cases are completely unusable. So he has to figure out what to do to tell in an objective way if he has a complete list, or if he has missed anything.Today we’ll talk about a few models that can help Blue.Who has had the long list of requirements like Blue? How did you know if your list was complete?
First, let’s talk about what requirements models do for us. There is a concept developed initially by a psychologist (George Miller in 1956) called Miller’s Magic Number, which is 7 ± 2. He demonstrated that people can only process 7 ± 2 things in their memory at a time. That means if we ask you to remember 12 things and think about them, organize them, and act on them, you likely cannot. Grocery store example – If I need to get 15 things at the store, I can’t remember them all. But if I know I need to get things from 3 sections, and in each of the 3 sections there are only 5 things, then I can probably remember it. So at a top level I know I need to get produce, meat and breads. When I go to produce and I remember I need bananas, apples, potatoes, carrots, onions. During that time I’m focused on produce, I can forget about what I need in meat and breads. (Be sure not to focus too much on the idea of memorizing here – and that it’s hard to do. Instead focus on the idea of understanding lots of information. )Remember Blue’s list of requirements – as he is reading through those, by the time he gets to #15, let alone #99, how could he know if he had them all and that they all worked together. Requirements models are used for the same reasons:Organize large amounts of informationFigure out what’s missingGive context to a collection of detailsFocus on a particular subset of requirements.When eliciting and reviewing requirements, models are much easier to look at than long lists of requirements. The models place the requirements in their proper context visually, and make it easier to see when things are missing. They also break up your requirements into digestible chunks, rather than complicated lists. It is much easier to check a small group of requirements for completeness than an entire system. Your models will help you break up a system into logical constituent parts and visually show the connections between those parts.
RML is basically a toolbox of many visual models that are specifically designed for requirements work. They have been tested through years of experience and hundreds of projects. RML provides you with pre-built templates for how to begin creating and using these models on your projects.On each project you will use only a handful of these models, and which models you choose will be dependent your project. Every project will require more than a single model, but no project should require all the models. In general, the more complex your system, the more types of models you should be using.The RML materials give you a pragmatic language of visualization models, providing you a set of tools to apply to your projectsEach model in the language: Is designed to be as simple as possibleConveys only necessary information about your requirementsIs easily readable by business experts and developers
Here are the models organized by the categories for OPSDModels are most useful when they focus on only one or two aspects of a system. If there are too many pieces of information modeled or the syntax is complex to understand, the model quickly loses its value. With that in mind, RML models are designed with the simplest syntax possible that still allows the model to convey the information needed.The language is a toolbox of models to choose from so you can pick and choose what you need at any given time.The RML models described today are the models proven to be most useful in analyzing software requirements. These are ones that we think you can apply to just about any project immediately, no matter where you are. You might do a slight variation on the pure model, but it should be something manageable. And it’s likely we are introducing you to at least one new model here.
This approach is one that most projects can implement at any stage, and will provide immediate improvement. You can see from this process flow, that the approach is simple, and we have purposefully designed it to be that way. We will be talking about each step of this approach.
[switch to Tony]Before we do, lets give you a quick introduction to Blueprint …..Blueprint is a modern, centralized, web-based requirements defn and management platform ….It lets you Author requirements using a wide range of Visual editors.It lets you Validate requirements with online reviews that leverage simulation, and can generate documents automaticallyIt lets you Manage requirements with traceability, versions and baselines, visual differencing, and the ability to reuse requirements – even across projectsIt lets BAs, Managers, and IT Leaders Monitor requirements activities, status, progress across a project or portfolio of projectsIt lets teams – whether colocated or remote – collaborate on requirements using a range of built-in social featuresSince Blueprint is totally focused on requirements and getting them right… we need strong integrations with toolsets in the rest of the lifecycle. To that end Blueprint provides <read>And finally its important to note that Blueprint is an Enteprise-Class solution - and a big part of that is an ability to administer across large, distributed teams of users. Blueprint provides a central ‘system of record’ for the requirements with access managed through role based security for users and groups. It’s also highly configurable allowing it to be tailored to suit the needs of individual projects and support virtually any process.
< switch to live product. 3min introduction>
Use your models to organize your requirements. Track relationship between multiple objects – we’ll add another object to this model shortly.Any objects on your projectReview - a requirements mapping matrix makes it easier for people to review the requirements, you can even use it in elicitation sessionsFind missing requirements - it also helps ensure you aren’t missing any – by making sure all process steps have requirements and all requirements map back to process steps. Find requirements you don’t need – if you haven’t mapped the requirement to a step, you probably don’t need it to execute a process, and therefore don’t need it at all.Instead of a spreadsheet or document with 1000 requirements, you can now filter and sort to subsets of requirements. This makes it easier for your subject matter experts to focus on the requirements that are of interest to them, or on the requirements that you want them to focus on. If you do not put some organization to the information, it will not be used – so all the hard work is for no purpose then. This can be done in word or Excel or a requirements tool. And this approach works for non-functional requirements as well.Doing them manually can be very time consuming
If you do capture UI requirements…and that’s a big IF, then typically they are captured with a list of requirements – and sometimes with a UI representation like a wireframe or screenshot. The problems with this are … Not very readableNo mapping of requirements to UIThere is no way to know if you have them allChallenging to develop from as it is disorganizedTo address these issues, we created the DAR model to put structure around these UI requirements.
You can then add the additional model information to your requirements, which helps ensure that the processes that have been defined can be completed within the screens that have been defined. Where there are gaps, this allows you to ask questions about those process sets that have no mappings. Additionally, if a UI element does not have any requirements listed, you know that you need to add those requirements to your list. This gives you the power to verify and check to see that you have a complete set of requirements.It also gives you yet another way to organize, sort, and filter your requirements.
[Tony]Say that all the earlier slides had BP shots. Now that they’re familiar with these images, going to show you where they came from and how all this can be supported .. In Blueprint 12-15min.
What we’ve discussed here is really just the tip of the iceberg in describing the RML toolbox. Our book describes the entire toolbox. It lists every model contained in RML and gives you the templates for using them on your projects. The three models discussed here are a great start for instantly adding value to your projects right now, but going forward you can add even more value by brining in more models that are described in this book.We have just discussed 3 models today. This book describes 22. If you think the models you’ve seen today are powerful, just imagine the power of being able to utilize all 22 models whenever they are required.Also, for more discussions about using models, see our blog where our practitioners talk about their experience in using the models in the real world.
As a bonus, we are giving you each a quick reference card with model templates on them, so that you can see what some of the other models are and imagine how they might be useful on your projects.