Requirements do not equal use cases or UML diagrams only. Use cases are a sub-set of doing requirements. There are also more ways of modeling than just using UML. Obviously it depends on the size of the project you are working on that will dictate exactly what your process will need to create. Let’s look at the bigger team size project and explore in simple terms what we should be doing for requirements and how this interfaces to the rest of the team’s activities.
Use Cases Only?
It seems that use cases have taken the industry by storm. Everyone seems to be doing them now. We do them because they are a great way of easily documenting what the goals of the customer are for the project. Having said that, I have seen projects turn use case molehills into use case mountains, and waste many hours arguing about includes and extends, use case levels, scenarios, etc. The trouble is that once the use case model is done, people feel it’s time to dive straight into coding. There is more to understanding what needs to be done, than just use cases.
We should assume that the technical people doing the coding have no idea about what the business does even if they have been there for a while. We should also assume that on a big project, as new people come into the project later on in the lifecycle that they will have missed communications and meetings that were held earlier. We should therefore spend time (time boxed) documenting the background and setting the scene.
Document the business to me requirements should start from defining what the business strategy is. Check out Icon Business Strategy as an example. Then align that with what the business does or wants to start doing in the future with respect to what the project is. We should define the problem in business terms. It helps the business see that IT has understood them correctly too. We should spend a certain amount of effort in modeling what the goals of the business are in the particular area. Define the business goals of their work by defining
Business Use Case Models
This will give you the goals of the business at a high level and the actors involved. This will set the context of external and internal systems and people for the area of business that your project will affect. In the simple example shown left and for the rest of the article, we have been asked to account for time spent on projects in the IT department and tell the accounts department how much time was spent on individual projects. The accounts people are external to our IT department. Along with establishing the business use cases, try and simultaneously document the
Business Vision for the Project
This is a textual document that you write after listening to the project sponsor and other involved parties (stakeholders and users) in the project. Make sure that they agree with what has been written. Use some of the higher level business use case diagrams like the use case diagram above, for example, in the vision document, this helps people get a visual handle for what’s being dealt with on the project. I see a great bill board advert in the station on my way home every day. It’s a massive billboard with massive words saying “glamorous model” and underneath in brackets “a picture is worth a thousand words”.
Visual modeling helps business put complex concepts into words easily. In the vision document you can define the features and stakeholder requests that our new envisaged system, should comply to. Also in the vision document you can justify the project from a financial and strategic point of view. You could have a separate business vision versus system vision, it really depends upon how much justification and selling is required to get the system’s project justified. Business Object Model
A business object model is defined by the business use case descriptions. This information will tell you about the business entities that are affected by the goals of the business in the context of our project. The business object model is a class diagram showing the entities and their relationships that are described in the business use cases. Against each entity you can textually describe the entity in detail, and this will double as the business glossary for our project by adding text against each entity.
Remember that everything we have defined so far is a logical definition of what takes place in reality. The descriptions do not assume how it will be implemented physically. The business models and text have nothing to do with any application or software system. For all we care this logical business description could be physically implemented using a blackboard, a box of chalk, a fridge magnet, a hand-cranked telephone, a few yellow stick-it notes and an abacus.
Doing business modeling is a lot easier to do when we are talking about a new system, because you can extract the pure business logic out of the discussion, but once we have to make enhancements to an existing computer system the logic easily gets blurred. It gets blurred because the business users constantly equate how the existing system works with the pure business logic. Now you and more especially your business experts are mentally biased towards describing what business happens by thinking about existing software implementations. They themselves may not even understand why they do it in a particular way; it’s just how they know it works. Try and keep them focused on the business reasons only. Now for the system requirements having defined the business problem, we now get to define the system requirements. First define the system use cases. This still has to keep a level above designing the system in that we have to describe in detail what has to happen, not how it is to happen. My advice here is to also try and define the system use case diagrams in parallel with documenting the textual system use cases.
It is important to remember to take a breadth first, depth later approach. In the first iteration, do one page documents for all use cases and basic matching use case diagrams. Pick a small sub-set of the most important use cases and have the architecture and designers design and realize them first, so that the developers can start implementing something, getting a simple automated build going as well as prove the candidate architecture. In this simple example we would have them realize and develop the print timesheet use case, as it would force them to define a stimulus coming into the user interface, a small amount of business logic defining a timesheet, as well as define database layers to persist the timesheet.
Take some time to look at the difference between the system use case model below and the business use case model above.
System use cases to realize the business use case. What we have now achieved is for the system use cases to realize the business use case. In simple terms we have taken a business goal described in pure business terms and created a set of systems goal requirements that will fulfill the business goal. It is not a technical solution, but rather a step towards partitioning the requirements of the users into more of what a computer system interaction should be doing to solve the business problem. We are documenting what should be done, not how it should be done. We have also traced from a business goal to a system requirement. Similarly, you would trace from the features a system should have to each system use case that will realize it. This would typically be done using a database type tool, because many of these requirements are textual in nature and there also are many-to-many relationships between these requirements. Other requirement and modeling types: business rules, non-functional requirements, UI screens, CRC cards, etc. While gathering your system use cases, you will also have been collecting business rules and non-functional requirements (NFR) and even getting User Interface Experience using use case story boards documented. My personal experience with gathering these requirements quickly and efficiently are to hold well planned workshops, interspersed with one-on-one interviews. This is potentially the subject of another article in its own right.
Business rules as with non-functional requirements can be gathered at different breadths of coverage. You may have some NFR’s which cover the whole system like “The system should access and display a timesheet to users in no less than 3 seconds”. While a more specific NFR may be something on a print timesheet use case happy case scenario like “timesheets should always print in Black and White, using a font no less than 10pt in landscape mode.”
Business Rules are rules to which the business people or system should adhere. In our example a few business rules could be: 1) Each employee must complete a timesheet by Friday of each week; 2) The smallest unit of time for timesheet recording is a quarter of an hour; and 3) Only the manager is allowed to define the project and time allocation categories for the timesheets, etc. These could be modeled using OCL in UML or you could keep them in a database or text document.
There are in fact a myriad of different types of useful artifacts that can input into requirements management. Have a look at the other artifacts in this Agile Requirements paper too. Here it stresses, less computer based, more manual capture of requirements. Analysis and Design
Having gathered our broad and not deep system use cases, the next phase is for the architects and designers to take their set of agreed upon high priority use cases, and realize them in a viable analysis model.
In the picture to the right, we have an analysis model of the print timesheet use case realization. This is one possible analysis level solution as to how we could potentially solve the “How we print a timesheet problem” showing all the participating objects out of the system for this UC realization. There are many possible solutions.
Remember that in the analysis model, we design a system in an ideal world with infinite memory, infinite speed and everything persistent and error free. Only in the design model later do we start bringing in the real world issues of space, time and technical issues such as architectures and layering.
Traceability As these or any other requirement types you may require, are being gathered, you should make sure they all trace to each other wherever any meaningful realize or dependency relationship exists. This is critical to ensuring that:
· You can calculate the impact of changes on a particular part of the system for better impact analysis.
· You can monitor and measure how the features the clients require, are solved in one or many a use cases for coverage. This can cause a trade-off on requirements requested.
While all of the above is very nice to have, it can mean a huge overhead on the process and in some cases may mean more work than the benefit it derives. Once it is tied into the configuration and change management, then it really starts giving back serious control to incremental and iterative changes on a project.
Integration to external disciplines If we ask the question, what other disciplines are related to the requirements management discipline, there is plainly an Input into the requirements gathering from:
· The business modeling discipline and strategy from the business.
· The change control mechanism managing changing requirements.
· Project management liaison collaborating on priorities and risks for the ongoing development.
· Taking advice from and collaborating with process engineering on tools from managing requirements.
· Taking advice from and collaborating with the Architect/s on the candidate architecture to best support the Users requirements.
It is also an output to:
· The analysis and design architectural discipline giving them use cases, business rules, NFR’s and UI documents to realize into their design models.
· Giving project management metrics on what use cases, business rules, NFR’s, UI documents and other artifacts are being worked on and how far they have progressed.
· Giving testing visibility of these artifacts so that they planning their strategy and implement tactical tests for each iteration. This also helps testers advise developers on unit test issues.
· Giving implementation (developers) visibility of the business and the requirements.
· Putting change by change into a configuration management tool, and doing version releases to other interested parties as and when documents and models are ready enough for working on.
Conclusion
Aside from coding, there is a lot more to requirements management than simply modeling and documenting use cases prior to diving into analysis and design. Requirements management itself is dependent upon input and output to and from many disciplines. It is also ongoing throughout the project lifecycle and is a collaborative exercise of communication and sharing of information, which is key to the successful development projects.
References
1) Rational Corporations, Rational Unified Process, 2002. See
2) www.rational.com/rup
3) http://www.iconprocess.com
4) http://www.businessrulesgroup.org
5) http://www.processwave.net
6) http://www.agilemodeling.com/essays/agileRequirements.htm
