Tips for Business Analysts: Requirements in Complex Systems

Author: Geri Schneider Winters

Some of you may be working on systems with many complex relationships between the parts. These complex systems may be described as a system of systems, or may be described as a product line, or perhaps both at once.

In these cases, you will often find that the requirements of a large, overall system are shared among a number of related projects, each of which implements some well-defined part of the overall system.

In this environment, it is really good to have a team of Business Analysts who work collaboratively on all the requirements of all the projects. Another approach is to have one or more Business Analysts work on the shared requirements, then have Analysts on each project work on the detailed requirements for that project.

If you do not have that kind of relationship between Business Analysts in your company, it is good for everyone to work informally with the Analysts on the other projects to share work as much as possible. This will lead to greater consistency and will avoid wasted effort in developing the same requirements multiple times.

You can use tools such as DOORS or Rational Requisite Pro to show the relationships between the requirements in different projects. For example, you might define a ReqPro project for a set of common requirements that all the projects share, then put a folder in that ReqPro project to store the requirements of one software project. That way, all of the related projects can see what is common and what is specific to a particular project. By reviewing the requirements of other related projects, a project team may find some similarities they can take advantage of.

If you have to keep one version of a set of requirements for one set of projects, and develop a new version of those requirements for another set of projects, then you would likely want to copy the first set of requirements, for example into a new ReqPro project, then edit the requirements in the new project. You can set up a trace relationship between the relationships in the two ReqPro projects.

I do not know DOORS, but assume you can set up similar structures in that tool.

A good book for project teams involved with complex projects is “Designing Software Product Lines with UML”, by Hassan Gomaa.

I have also written a paper with an example of a system of systems/product line approach to requirements. It is called “Requirements Structure in a System of Systems / Product Line Architecture. You can find it at:

http://www.writingusecases.com/wordpress/index.php/
report-requirements-structure-in-a-system-of-systems-product-line-architecture/

===============================================

Now it is your turn.

Are you working on a set of complex, inter-related projects? Are some of the techniques suggested here or in the paper useful to you?

================================================

You are invited to re-publish articles from this blog, in your publication or website, as long as the article is intact and you include the following Byline paragraph (with live links) after each article you use…

START BYLINE

* Article used with permission from Wyyzzk, Inc.’s Resources for Business Analysts site at http://www.writingusecases.com This website of reports and tips contains information to help you succeed as a Business Analyst in IT.

END BYLINE

Tips for Business Analysts: Managing Requirement Changes

Author: Geri Schneider Winters

Almost every project will have to deal with requirements that change. I can imagine some maintenance type projects that are so well defined (fix this list of bugs) that there are no requirements changes for the lifetime of the project. Or perhaps the project is so short (a couple of hours) that there are no requirements changes. But all other projects will have some amount of requirements change.

You could argue that XP projects do not have to deal with this. In XP, a developer works directly with a customer to implement a small amount of functionality. So that small amount of functionality will probably be completed without change. But as soon as the customer sees the results of that functionality, they will want something more or something different.

This is one approach to dealing with changing requirements. Define a small amount of functionality, write the code for that, and demonstrate it to your customer. Get their feedback. Now define another small amount of functionality. This could be any combination of new features and changes to existing features. Write the code for that small amount of functionality and demonstrate it to your customer.

Sound familiar? It should. This is a brief description of a basic iterative development process. XP is an iterative development process, as are RUP and EUP. All iterative or spiral processes were defined for the purpose of dealing with the problem of requirements that change throughout the project.

The key to this is to *not* define all the requirements at once, but to only define enough of the requirements to be able to write some code so you can demonstrate it to the customer.

“But”, you say, “even though my company does iterative development, I am required to write all of the requirements at the beginning of the project and to get them signed off by the stakeholders before any development work is complete.”

Basically, you are describing a process that is waterfall at the beginning, followed by a series of development releases. This is really a modified waterfall. I think what drives so many companies to this process is that upper management wants an estimate of project cost up front, and to estimate the cost of the entire project basically requires you to describe all of the requirements of the project at the beginning.

(Side note: Another way to estimate project cost is to compare what you know about this project to similar projects in the company’s past, and use the final amount of the cost of the previous project as the estimate for the current project. Of course, this requires that the company keep information about previous projects in such a way that it can be found later.)

In this situation, your project must either adjust to each change as it comes along, or define a process to allow you to bundle a set of changes and deal with those changes at well-defined points in time in your project.

This latter way of doing things is preferred, since it minimizes the impact of change on your project team. An easy way to do this is to wait until the development team reaches the end of one of their cycles of development, and introduce the changes when the next set of functionality is being designed. This is less of a disruption on the development team than giving them changes whenever they are discovered.

Another issue arises when considering the impact of change on the project timeline and budget. If you are required to accept every requested change, your project will go over time and over budget. If you cannot exceed your resources, then you will have to add to the change process a mechanism for deciding how much the change will cost, and what the project will give up in exchange. You have to pay for changes somewhere in the project. Either you get more time and money to develop the product, or you pay for changes by not developing something that was originally planned.

This is just basic budgeting as we all practice it at home. If I have $5.00, I can buy a Venti Chai Soy Latte at Starbucks, or a Big Mac meal at McDonalds. But I do not get to buy both. I have to pick one or the other to spend my money on. The same is true on a project. If you have $10,000 to spend, then to add feature A which costs $10,000 you have to remove another feature from the project which costs $10,000. This is very easy to understand, but so many people want to believe that adding new features to the software is somehow free.

I have had fairly good success at positioning requirements changes in terms of cost (time and/or money). So instead of saying, “If you want A you have to give up B” or “We can’t do that within our time and budget”, I tell the customer “You have so much money to spend on the project and it is all allocated to development costs already. This feature you want will cost $10,000 to develop. Where do you want that money to come from? Can we add $10,000 to the budget, do you want to give up something else worth $10,000, or is this new feature not important enough to spend $10,000 on?”

Estimating the cost of the changes and presenting that estimate is part of my process for changing requirements. I do not tell the customer “No”, I tell the customer the cost and the consequences and let the customer decide what to do.

===============================================

Now it is your turn. What is the approach to handling requirements changes at your company? There always is an approach, even if that approach is to try to ignore the change requests and hope they go away.

================================================

You are invited to re-publish articles from this blog, in your publication or website, as long as the article is intact and you include the following Byline paragraph (with live links) after each article you use…

START BYLINE

* Article used with permission from Wyyzzk, Inc.’s Resources for Business Analysts site at http://www.writingusecases.com. This website of reports and tips contains information to help you succeed as a Business Analyst in IT.

END BYLINE