Transforming a User Story into a Functional Requirement

Page content

From User Story to Requirements

Functional and Non-functional Requirements

Your first job is to ensure that the concept of functional and non-functional requirements is used correctly, because this is the first problem many projects have trouble with. No system should try to fulfill a non-functional requirement because by definition non-functional requirements are superfluous.

The term non-functional requirements tries to differentiate features that calculate, store, or modify data from those that describe soft or even non-functional features like performance, usability, or appearance of the screens. That’s an inaccurate idea. Even a feature that deals with response time is definitely functional. We define this requirement because we need a defined response time for at least one reason. Thus, it is a functional requirement.

When trying to implement requirements, ask yourself if there is a real demand for each requirement. Studies have shown that up to 50 percent of the features implemented in large systems were not used during the first year after installation; even after that time this rate did not change dramatically. That tells us that a careful discussion of features is mandatory to examine the use case of each feature on the list. Let’s have a look at the whole process.

From the User Story to the Requirements

Start acquiring user stories by asking the customer about the processes that let the requirements occur. The process is noted on small cards, and can be explained in about three sentences. Take all these cards and make sure you notice which user story originates from which stakeholder to ensure good traceability. On the back side of each card we now develop a use case diagram that visualizes the processes derived from this user story. While doing this, ask if each user story:

  1. Is really necessary
  2. Is programmable
  3. Is profitable (measured by the return on investment (ROI) – even internal projects need a ROI)
  4. Really has context to the system it has to be integrated with or the project that is coming up.
  5. Is in order with the processes defined in the company to avoid growing rain forests of IT toys.

If a story card does not fit one or more of the above reasons, it is not destroyed but put into another box for later discussion.

Now we have good user stories, and a first idea of the processes depending on the user stories. That’s why we should avoid accepting “requirements” from outside the IT department or the customer.

Build the Use Case Chart

When there is common clarity about the user story and processes, we start to fuse the single use case charts into one big use case diagram. This diagram will show the process of the features to be implemented later in a big picture. In most cases we now find a lot of redundancies and poorly described processes.

The big picture is now improved: We optimize processes, reduce redundancy, and simplify where possible. We answer the question, “Do all the use cases we see in the chart have to be completed by the IT system or can some of them be better handled by a co-worker?” This question is rare in IT because software engineers normally make programs of everything they can code – and that’s nearly everything that happens in a company. But to calculate a ROI, you need a demand and the total cost of ownership (TCO).

Define the Feature List and Start Requirements Engineering

After having finished the use case and evaluating the business case for the actual requirements, we can write a feature list. The feature list is then transformed into the four main categories of requirements (customer, developer, quality, security requirements). These requirements are sometimes done when doing a project as an external service for a customer but, surprisingly it is almost left out when we get requests from inside the company that have to be done by the company’s own IT department. However, the requirements are written, improved, and labeled as usual. Some methods for doing this are described in later articles.

The requirements now go to the design phase and then they are implemented. See the next article for these steps.

This post is part of the series: Implementing Functional Requirements in IT

Implementing functional requirements in IT is very wide spread in its details. This series shows some of the Decisions we have to find, some ideas we have to deal with to avoid mistakes, underestimation of costs and to ensure good quality, low costs and perfect timing.

  1. Implementing Functional Requirements in IT: Part 1
  2. Different Requirements Demand Different Implementations
  3. Why Managing Change is Critical to Implementation
  4. Three Examples of Implementing Functional Requirements in IT