requirements modelling

Overview

Designing a large and complex system is a job that must be done in stages. A lot of decisions are bound up within the deployed implementation; we need to make the biggest decisions first -- that is, the decisions that affect most of the rest --- and defer the smaller ones. Bigger decisions are about requirements and the overall architecture; smaller decisions include the design of specific routines or the naming of local variables. 

Programming languages are very good for expressing the end result of the decision making process, telling the machinery what we want it to do. But they aren't very good at expressing part-finished designs: the big decisions without the fine detail. That's why we use modeling languages such as UML (or less well known ones like ODP).

Modeling language allows us to talk clearly about the high-level aspects of design, whether discussing things at the whiteboard, or describing a design for the benefit of future maintainers. It enables us to think and communicate clearly about the most important issues, without the clutter of implementation detail.

Although a model is abstract, it need not also be fuzzy. Traditional requirements documents, written in English and illustrated with ad-hoc diagrams, tend to be ambiguous and inconsistent; progressing the design towards the program code increases detail and precision at the same time. During the process, issues glossed over in the requirements spec are raised --- sometimes quite late in the schedule, resulting in last-minute fudges. 

But it is the precision, not the detail, that exposes the gaps and inconsistencies. Precision means being exact about what your statements do and don't imply. Used properly and to the full, modeling allows you to be precise about the high-level issues. Because you're being abstract, you can cover all of a large system in a short time; because you're being precise, you discover lots of questions about the requirements that you can take back to the customer.

Benefits

Constructing a good model therefore 

• Increases your confidence that you understand the customer's business domain and needs; and increases their confidence that they are going to get an appropriate system. 
• Decreases late fixes when inconsistent requirements are discovered or after the customer sees your first delivery.
• Reduces ad-hoc and incoherent decisions during design.
• Reduces overall costs of development.
• Makes maintenance easier.

Business modeling

Modeling isn't just used for describing the requirements or architecture of a program. It can be used to describe the concepts and activities in a business domain, entirely separate from any single piece of softare. There are several uses:

• The software is there to support the business. It is therefore a useful first step to describe the business, before going into the role of the system within it.
• If you design several systems within the same domain, they will use some of the same concepts. Making a common definition of those concepts gives you a head start in understanding and documenting the requirements of any one system.
• Where components are coupled together, it's necessary to describe their connections --- particularly in component based development, where there may be many possible configurations. To describe what the components are talking to each other about, we need a common business model. This has to include not just data definitions, but also information about business rules and activities.
• It can be very useful to model a business domain just for the benefit of the business, so that everyone is talking the same language; particularly where we are trying to manage the integration of a large enterprise.

The Strategy

We generally begin a project by constructing a model of the principal concepts in the domain. This can act as the basis for component requirements and designs, and interface definitions. Models can also be used as the basis for describing changes to existing systems - software requirements management should make explicit the refinements of any SRS (software requirement specification).

It is sometimes better to go straight for building the software, without any modeling. This is the case where the end-product is small or can be made quickly by assembling existing components. In any kind of project, an aim should be to give the customer feedback about what you're providing for them, frequently and as soon as possible. The most effective feedback is an actual working system (even without most of its features): if this can be done very early, that's great --- it's what CBD is about. Otherwise, the most useful early feedback comes from the many questions generated by the elaboration of a model.

complete solutions for requirements engineering
(consultancy, courses, workshops, mentoring, seminars, development)