The Requirements Engineering Magazine appears quarterly. It is cost free and provides you with up-to-date articles reflecting the activities of the RE and BA community.
Simply sign up for being notified about new issues of the Requirements Engineering Magazine.
You may unregister at any time by sending a mail to firstname.lastname@example.org from the e-mail address which you have registered with.
We are in the machine industry. A company was willing to change the working mode of the software development department as part of a huge Research and Development (R&D) project, supported by consultants to help establish and develop processes, roles and responsibilities as needed.
We worked closely with the System Architect (SysA), the software Product Owner (PO), the software team and some other involved people. Early workshops showed a deep discomfort among the developers concerning the requirements and specifications.
We found different requirements documents for different project stages with different authors (see Figure 1). The landscape of existing document types was complex, sometimes overlapping, with some gaps and all of them in a style developed years ago in a waterfall context with customer requirements specifications, system requirements specifications, and many more Word documents. Some central documents were required to pass a project gate but the quality criteria were unclear; the later use in the product development project depended on the people in the project. No requirements management beyond versions of a Word document was established. The requirements abstractions were mixed throughout the documents: in the customer requirements document (CRS) high level and very detailed requirements were side by side in a long list of requirements.
There is some information that is important during the project at some stage, but it is typically not of any further interest as soon as the project is in another phase or finished. Other information, however, should be kept up to date and may be of value after the project. How do we decide which is which? We asked the team which information would be helpful for them when they need to start with a minor release version, say version 2.3, of an existing product. Where do they look for the information now, and how could we organize it better?
With this guideline we structured the “document landscape” into product-driven documentation and project-driven documentation and added new types like coding principles and code comments to our landscape, as they also document important aspects of the product. Figure 2 illustrates an example.
The documents were typically associated with a certain level of details even though the documents of the current project did not fit the expectations. It was important to understand which people in the company have the domain knowledge, and at which detail level. The product manager is not the expert of the so-called “system check” that the production line needs for validating the built system, but has to know:
Together with the Software Team Leader, the Product Manager (PM, a member of the marketing team) and the Product Owner (PO, a member of the software team) we structured the requirements levels as needed and based on the landscape of documents, and we found a gap that had led to many discussions between the Product Owner and the Product Manager. We bridged the gap by introducing the feature tree: the feature was the right level to hand over from PM to PO, while the tree was the structured view on the features. For the transition see Figure 3.
From a requirements level’s point of view the feature builds a bridge between the user stories of the software project’s world and the product user’s view. Each feature has its stakeholder(s): they are involved in the specification of acceptance criteria and testing and ensure adequate quality.
The feature description is often represented in table form based on a company-specific template: some items are general feature description items or fields (e.g. see Table 1), some are company-specific items.
|ID & Name||nnn xxxxxxxxxxxxxxxxxxxx|
|Class||Core, Base, Feature|
|Pre-condition||Feature reference, states|
|Stakeholder||[Who delivers details and tests]|
|Feature size||[S, M, L, XL]|
The specification of a feature can be
Features are a common abstraction level, sometimes above the epics in the hierarchy (see Figure 1), sometimes below. A feature is a set of requirements (functional and non-functional), has a business value for a stakeholder and might have dependencies. A feature lasts longer than the project and might get additional sub-features in later releases.
During the development project a feature is broken down into user stories, and later into tasks, by the development team.
Features have an ideal abstraction level for communication and discussion with stakeholders about how the product really needs to be valued. Features sometimes come in lists like a backlog or in tables or are sometimes visually structured: these are the feature trees. In general there are two types of feature trees:
The example in figure 4 shows that the tree is compact and needs some work in advance to identify the requirements and the right order for their development. The product manager is usually not able to create such a feature tree on his own: he needs the know-how of the development team to realize it. In general, the mind map version of a feature tree is simpler and more quickly achieved. It decomposes the problem by breaking down the product into feature sets and features and delivers quick wins:
The feature tree lasts as long as the product. What is hidden by many feature trees are the requirements (functional and non-functional), as they are parts of the features.
Hint: In general, careful selection is required of what is visible in the tree and what is mentioned in the feature description (specification) only. Too many kinds of dependencies confuse the feature tree: try to focus on those that are the most relevant for the stakeholders.
Feature vectors are a powerful technique for project planning as they show how a feature is developed over time: how much of a feature is needed for the user at a particular time, how much does it cost and does the business value justify the costs.
|Feature||Increment 1||Increment 2||Increment 3||Increment 4|
|Service Management||Block/deblock vehicle
Enter service dates
Define service types and work packages
|Log service history||Automatic reservation for service|
|Fleet Management||Define vehicle categories
Enter vehicle place
|Change vehicle place
Search by category
Search by place
Add categories dynamically
|Order vehicle move to another place|
|User Management||Login/Logout||Change password||Set preferences|
Developing the feature tree and describing the features is often an iterative process: while working on the details you might identify modifications for the tree and vice versa. In Table 3 some findings are listed highlighting how one might deal with them.
|Aspect||Description||How to deal with it|
|Different types of features||Differentiation between mandatory, optional and alternative||Visual mark in the tree plus text in the feature description|
|Product variants||Some features might only be relevant to some product variants||If useful: visual mark
Feature description: field “Product Variants” to enter all product variants that offer this feature or “all”
|Dependencies of features||A feature on the same level or in a different branch might require the solution of another feature.
Mind: this is a business dependency (not a technical one)!
|Recommendation: describe the dependency in the description of the successor (if you show it as a link the picture gets crowded) and/or the post conditions. Additionally, link the pre-conditional requirements of other features as ‘predecessor’.|
|Acceptance criteria||Similar to user stories a feature also needs acceptance criteria. These criteria might be defined per vector and finally overall.||Add a field “acceptance criteria” (like it is used for user stories). Add the stakeholder (group) to accept the developed feature to close the quality loop.|
(top level feature)
|Does a feature set (or “base feature”) need an own work item type?||Use the feature item as a feature set is a feature of “higher” level (direct link to the root).|
|“Empty” feature||A feature might just indicate a category and does not have linked requirements and user stories: it just helps to structure the tree.||That is ok. Check if non-the-less acceptance criteria might be helpful. Use the feature item.
If it happens in a later phase that requirements are linked to a category feature the full set of information of a feature has to be added to the item: it becomes an ordinary feature.
|Business rules||Re-usable requirements can be implemented as business rules that allow adaption via parameters to fit for the purpose.||Within the feature tree the business rules are handled like an ordinary requirement.|
|Unsolved requirements||If the feature is built with a subset of all requirements (instead of all) it has to be defined what happens with the open requirements.||
|Feature state||How can I handle ideas or drafts within the same feature tree?||A “state” can indicate e.g. whether a feature is merely an idea, has been checked with stakeholders or is ready to be planned by the team. Some states might not be visible in the tree view.|
Color codes or frame codes can visualize additional information. For example:
There are many possibilities to visualize information but the important thing is to concentrate on the information needed per stakeholder group. The Project Leader wants to communicate other aspects to his steering committee than the Product Manager to the production management when he wants to check the priorities of the “system check” features.
Hint: be careful with colors. It is surprising how many people are color-blind in some way (if you are not color-blind yourself!).
The agile development setup was embedded in a milestone-driven project management setup. To allow planning, to handle expectations, and to prioritize the work items it was important to make visible what results are possible with the chosen setup and resources. It was important for the Project Leader but also for the management and the team.
Step 1: Common understanding of the feature tree by Product Manager, Product Owner and Project Leader. An additional solid check with the system and/or software architect that the structure of the tree is aligned with the architectural view (otherwise: think about re-structuring the tree).
Step 2: Common understanding of the goals per milestone (Prototype 1-3, Alpha Test, Beta Test …)
Step 3: Identifying the features that have to be delivered per milestone.
Step 4: Check and define the feature vector: “how much” of the feature is needed per milestone.
Step 5: Check dependencies and ensure that pre-conditions are included in the planning.
This procedure leads to a rough prioritization of the features and their location on the time axis: the first draft of a roadmap. To ensure feasibility with the given time and resources we need to estimate the features (see step 6).
Step 6: Estimate all features on the roadmap.
Usually, there are now too many features on the roadmap. The project leader discusses possible measures and their consequences with the product manager and the product owner, for example: fewer features, more time or more developers (if this helps and is possible).
The initial effort to create and design the feature roadmap was quite high but very important. The feature roadmap developed into a central part of the project planning and coordination.
The initial phase of creating a feature tree and a feature roadmap delivers a solid base for a project. The tree is now in a living state: it grows and changes over time. New features are added, deleted or changed. In some cases the tree might have to be partly restructured to allow for a new feature. The company needs processes and roles to manage the changes and to keep the feature tree up-to-date over the lifetime of the product.
With the introduction of the feature tree changes were initiated in a number of different areas:
Most of the initiated discussions and changes are not surprising. As the feature tree is not a technique to solve the problems of one person only but a communication vehicle it has to be embedded into the environment of the involved people – improving existing procedures, adding new ways, changing views, and giving an impulse to change in other ways as well.
One of the main lessons learned was that the feature tree is not just a new technique but − as seen in the last section − a starting point for changes. We didn’t need a perfect tree to start, a small plant was also a good starting point. Especially the release planning aspect was highly appreciated by the customer as it led to transparency, a common understanding and therefore to more profound decisions and prioritization.
The idea of decomposition was easy to grasp and delivered results quickly. The feature vectors were seen as an important additional aspect but the visualization variant as shown in Figure 3 led to misunderstandings and discussions. So we took the version of a mind map and differentiated the vector by sub-features: each vector was added as a sub-feature, the name indicated the additional business value. See also Table 2 for a vector in table form.
The feature tree allowed modifying and lightening the documents landscape: some formats were changed, some added, some documents vanished. We created a new template for the customer requirements specification and defined it as a counterpart to the feature tree. The template includes instructions that refer to the feature tree and focuses on additional information (i.e. not visible in the feature tree), or helps to explain the customer needs and the feature tree better. It also gives an overview of typical stakeholders and therefore helps to identify the stakeholders of the current context.
As soon as the usage of the feature tree is established it is recommended to review the requirements process and its products to see if they still fit:
Ideally new methods are introduced in very early stages of a project and not in the development phase. When the consulting started it was not the goal to introduce a new requirements method. Nevertheless it was the right decision, and we found ways to handle the consequences and find good solutions with the company and its teams.
Although we promoted the Product Manager as the owner of the feature tree we chose the Product Owner as “master” of the feature tree, meaning the Product Manager is responsible for the content and the Product Owner keeps it up-to-date as he works with it on a daily basis. The main reason for this decision was that the project was already running.
A consequence was that the PO had difficulties in defining features. He had the list of requirements at different levels but not the domain or customer context that was needed for the features.
As the responsibility for the feature tree was laid into the hands of the Product Owner we looked for a tooling solution of the feature tree that fitted best for the Product Owner. His main instrument was the Microsoft Team Foundation Server (TFS). Here were all his stories, his categories and references to his requirements – it was the central view for him and his development team. So they created a new type “feature” next to user stories and epics and used a graphical add-on to generate a tree view. From the company’s point of view the integrated tooling was a key success factor.
Although the article is written in the past the change in the requirements engineering is still going on – in the same project and in new projects as well. Once in a while a review will take place to see what works well and where there is room for improvement. There are always new events changing the set-up in an unexpected way. So we still inspect and adapt to improve the communication and synchronization. In the end it is not the technique we want to improve - though that might be a by-product - but the way people work together.