Requirements Model - Org Chart

At the very beginning of a project, you need to identify who has an interest in the system and who will be using the system. We often overlook the org chart as a very simple starting point on a project. However, it is a model that can be used to identify the stakeholders and users of your system. If you have an org chart for your entire company, you can rigorously look at each block on the chart to decide whether it represents a stakeholder, user group or both.

If your system is an internal IT system, all of the possible users are somewhere on that org chart. Therefore, by using it as your starting point, you can simply select your users from the chart. If you have external users, there are still going to be stakeholders on the org chart who represent the user populations externally, and identifying those representatives within the org chart will help you find their counterparts outside the organization.

On one particular project that touched many different parts of the organization, we used the org chart as our basis for identifying all the user groups. We plastered the walls with all of the sections of an org chart. Our project sponsor came through the room, and for each section of the org chart, he could easily either “X” through it or “*” it for us as a group we needed to talk to. From that, we could quickly focus our conversations with each part of the org and determine if they indeed were users or had some stakeholder-level interest in the project.

The org chart itself is not necessarily a useful model to include in the final requirements document, but rather a tool to help find the users and stakeholders. Once you have used your org chart to identify users and stakeholders, you should be able to form a concrete stakeholder list for requirements session interviews and sign-offs and an actor list to use to identify use cases and user profiles. One word of caution in taking the step from the org chart to user groups to actor list - there may not be a one-to-one mapping of user group to actor, as often an actor may cross various organizational roles or vice versa.

The main issue with org charts is that many organizations do not have an org chart ready to use. If you have to create one yourself, the model still works, but now much of your energy is spent on ensuring you have the right org chart. This can be a useful activity to do, however you probably would not think of this activity as “creating an org chart” but rather just identifying the users.

As a final note, this model does not really help you identify any system actors. Later, we will talk about system context diagrams and data models to facilitate this.

CMMI and Requirements Part I

CMMI and Requirements Part I
A lot of our clients are looking at CMMI-Dev (http://www.sei.cmu.edu/publications/documents/06.reports/06tr008.html) to see how their software development organizations can benefit from it. However what I have noticed is that many people refer to CMMI as a process. CMMI is actually a framework for developing and improving processes. What does this mean? This mean the CMMI does not prescribe step by step what you should do, instead they give "Specific Goals" and "Specific Practices" which describe what criteria a process should satisfy. CMMI defines 22 process areas and 5 (or 6 if you count zero as a level) levels of maturity. Two of the process areas are related to requirements, Requirements Management which is a Level 2 process and Requirements Development which is a Level 3 process.

The 6 levels are:

The CMMI-Dev specification defines a requirement as:
(1) A condition or capability needed by a user to solve a problem or achieve an objective.
(2) A condition or capability that must be met or possessed by a product or product component to satisfy a contract, standard, specification, or other formally imposed documents.
(3) A documented representation of a condition or capability as in (1) or (2).
There are two Process Areas related to requirements, Requirements Development and Requirements Management.

Requirements Development (Level 3)
• SG 1 Develop Customer Requirements
– SP 1.1 Elicit Needs
– SP 1.2 Develop the Customer Requirements
• SG 2 Develop Product Requirements
– SP 2.1 Establish Product and Product Component Requirements
– SP 2.2 Allocate Product Component Requirements
– SP 2.3 Identify Interface Requirements
• SG 3 Analyze and Validate Requirements
– SP 3.1 Establish Operational Concepts and Scenarios
– SP 3.2 Establish a Definition of Required Functionality
– SP 3.3 Analyze Requirements
– SP 3.4 Analyze Requirements to Achieve Balance
– SP 3.5 Validate Requirements
Requirements Management (Level 2)
• SG 1 Manage Requirements
– SP 1.1 Obtain an Understanding of Requirements
– SP 1.2 Obtain Commitment to Requirements
– SP 1.3 Manage Requirements Changes
– SP 1.4 Maintain Bidirectional Traceability of Requirements
– SP 1.5 Identify Inconsistencies Between Project Work and Requirements

As you can see, the Specific Goals and Specific Practices are quite high level. Therefore, there are a number of processes that could satisfy the criteria. The key point is that the CMMI describes the areas of a process that should be examined. In subsequent articles I will examine how various processes satisfy the letter and the spirit of the CMMI requirements process areas.

One More User for Use Cases, Continued

In an earlier post, I discussed a presentation I had attended by Richard Denney and mentioned that his book, Succeeding With Use Cases: Working Smart to Deliver Quality, was on my reading list. I've now read it, and it's a good read. The book does a great job of taking academic, involved principles and distilling them to practical application. A great example of Denney's tone is in his preface; he has a section titled "For Those Who Hate Math" that warns the reader about the chapters of the book that involve real math.

As a product manager, some of the chapters were less interesting to me, such as those on leveraging use cases for testing. But, in his preface Denney had noted which chapters would be of interest to the various roles within software development. The chapters I most enjoyed were the ones that explored how to use Use Cases to:

• Drive a vision vertically through a project.
• Align an organization horizontally.
• Quantify the frequency of use of use cases.

There is no surprise that these were some of the chapters Denney recommended for product managers.

If my earlier post made you curious, or if the chapter topics I enjoyed intrigue you, check out the book.

Views of Requirements

There is an architectural pattern in software engineering known as Model-View-Controller. This pattern suggests (among other things) the separation of data (Model) from the display of that data (View). The reason for this distinction is that there may be many different ways to display data in a way that is useful for the consumer of the data. An accountant may want to view financial data in a table, while executive management might prefer a pie chart.

There is a similar pattern that we can apply to requirements. At the risk of overloading terms, Requirements (data) have different Models (display of data). The models that we use are basically ways of displaying data to the consumer of that data. A tester may be interested in a long list of "System shall..." statements, because each statement gives them an opportunity to write a test. A system architect may be more interested in Swim-Lane Diagrams because they highlight the interfaces between systems. A business user may be most interested in Use Cases because they allow a review of how they use the system. A GUI designer may be interested in Click-Action-Response Tables since they specify how some elements of the user interface interact. The Models aren't the requirements, they are a "View" of the requirements.

Reminder: State the Obvious

Sometimes quick reminders are helpful, so here's one: when writing requirements, state the obvious.

Reasons:

• What is obvious to one person isn't necessarily obvious to another. This can even hold true when both people are geniuses.
• With multiple priorities and demanding schedules, we sometimes lose track of the obvious. Having it written down helps us remember it.
• It helps us find the exceptions to the obvious.