Features that customers do not use after the release are a big source of waste. The main reason for this problem is the lack of customer centricity during the traditional product-centric analysis and design approach.
Defining the details of user requirements by employing the “use case” technique in waterfall methodology and the “user story” technique in agile methodology helps project teams be more customer centric.
Use Case Technique:
In waterfall methodology’s use case–driven analysis, user requirements are defined in three steps:
- Who are the actors? Target actors are
2. What are the goals (use cases) of actors?
User requirements (use cases) correspond to the goals of the actors. Use cases are shown on a use-case diagram, which also illustrates the high-level scope.
For the CEC mobile application development project, the use case diagram below was defined:
3. How will the actors achieve their goals?
In waterfall methodology, the activities of actors to achieve their goals can be shown on use case documents.
As mentioned earlier, the scope of the CEC mobile application project’s first phase included only “View and Order a Product “and “Compare Products” use cases. The interaction of the CEC customers with the mobile application to achieve these goals was defined on use case documents. The “View and Order a Product” use case was documented as follows:
In use-case documentation, the following best practices should be considered:
-Scenarios on the use case document describe the activities of actors while achieving their goals.
-Each scenario step (activity) corresponds to a functional requirement.
While applying the use-case technique, there may be confusion about the difference between a use case and a functional requirement. Actually it is quite simple. Each use case represents a particular goal of an actor, whereas the activities to achieve that goal are functional requirements.
Let’s explain this relationship with an analogy: If a bottle is considered a product, “drinking water” is a use case, since it is a goal of an actor in using the bottle. But “opening the bottle cap” is not a use case, because it is not a particular goal of the actor. People don’t buy bottles to open and close their caps. Opening the bottle cap is just a functional requirement to reach the goal of “drinking water.”
Similarly “View and Order a Product” is a use case for the CEC mobile application, whereas “category selection” is one of the several functional requirements to achieve that specific use case.
-Separate main, alternative, and exception scenarios of the use case.
The main scenario on a use case document represents the positive flow (happy path) of activities to achieve the goal of the actor in normal conditions.
Alternative scenarios define other possible ways of achieving the same goal.
Exception scenarios define the activities of the user in exceptional and error conditions.
For the “View and Order a Product” use case in the CEC mobile application, if finding an item by navigating through categories is described in the main scenario, then the discrete activities needed to find that item by using the “Search” functionality should be defined within an alternative scenario. The interaction between the customer and the CEC mobile application when the customer attempts to order an out-of-stock item should be defined as an exception scenario.
-Define exception scenarios separately from alternative scenarios.
Alternative scenarios may include some nice-to-have conditions that can be
postponed until future releases, in case there is latency in the project. However, exception scenarios include error conditions, and they have to be implemented in any case.
-Use case documents aim to answer what (functionality needed in order to meet user requirements) and how (nonfunctional requirements and business rules) questions.
Clarifying the technically how (inner technical dynamics) question is not a use case document’s objective. Therefore, don’t include technical details on use case documents. According to the “just in time” principle of the lean approach, technical requirements should be defined later in a separate technical design document.
-Define use case scenarios with the users’ point of view, but don’t include user interface details. Those details are defined later on prototypes and in user interface annotations based on use case scenario definitions.
For example, “customer selects category by clicking buttons at the middle of the screen” is a wrong scenario activity definition. “Customer selects a category” is just enough.
-In addition to functional requirements, also define nonfunctional requirements, business rules, and assumptions on use case documents.
-Define business rules in a parametric way.
This will let the project team easily design, develop, and change business rules when needed.
For example, in the “View and Order a Product” use case, “User is notified with a message indicating that 1 percent commission will be charged for express deliveries” is a wrong functional requirement definition. Instead it should be defined as “User is notified with a message indicating that a commission rate will be charged for express deliveries (BR1).” Business rules in this scenario should be defined in the business rules section of the same use case document. The business rule in this example should be defined as follows:
BR1: Express Delivery Commission = 1 percent
-Define nonfunctional requirements, such as usability, performance, and privacy,
for each use case in a verifiable (testable) way.
For example, “After the customer confirms the payment, an Order Confirmation Report should be displayed fast” is not a correct performance requirement definition. It should be defined as “After the customer confirms the payment, an Order Confirmation Report should be displayed within two seconds.”
-Limit assumptions to the conditions in which the user has no control.
For example, “Product availability data received from the ERP inventory module is up to date and accurate” may be an assumption for the “View and Order a Product” use case. But “the items that will be ordered by the customer are in stock” is not a correct assumption. The behavior of the customer and the CEC mobile application, in case the customer attempts to order an out-of-stock item, should be defined as an exception scenario on the use case document. Otherwise unclarified assumptions will create many issues at the user interface design, technical design, and development stages and result in waste due to unplanned work.
-Benefit from flow charts to visualize use case scenarios.
In history, people first used drawings to communicate with one another. Even after the invention of letters, they continued to use drawings as an easy way of expressing themselves. Similarly, using diagrams such as flow charts is an effective way of visualizing use case scenarios and clarifying the ambiguities in narrative requirement definitions on plaintext, use case documents
Flow charts are useful for modeling and describing work flows with simple diagramming conventions. A flow chart should be created for each use case. Each branch on a flow chart represents the main, alternative, or exception scenario of a use case.
The flow chart below represents the “View and Order a Product” use case of the CEC mobile application. The branches on the chart show scenarios of that specific use case.
User Story Technique
Unlike waterfall, agile methodology focuses on “working products over comprehensive documentation.”
In scrum, requirements are defined as short and simple user stories (As a “role,” I want “goal”) in parallel with the above manifesto statement.
As mentioned earlier, agile scrum methodology was applied at the second phase of the CEC mobile application project. Instead of detailed use case documents, simple user stories were defined at this phase.
Some of the user stories included in the product backlog of the CEC mobile application project were as follows:
-As a user, I can comment on CEC products so that other customers can learn about my experience.
-As a user, I can rate CEC products so that other users can benefit from my opinion in making their buying decisions.
-As a user, I can see the comments and ratings of customers posted via the mobile application, also on the CEC web page, so that I can make a better decision in product selection.
-As a user, I can search for the address of the nearest CEC dealer stores so that I can go and view the products I plan to buy.
-As a user, I can track the status of an order so that I can arrange my time for delivery of the product to my home.
-As a user, I can cancel my order on the mobile application so that I don’t have
to contact the call center.
-As a user, I can get campaign offers on the mobile application when I am near a dealer location so I can visit the store and view the product with a discounted price.
-As a user, I can get discount coupons when I connect to a CEC product via mobile application so that I can use them to pay less for my later purchases.
-As a user, I can log in to the CEC mobile application also with my social media accounts so that I can easily post information about CEC products.
User stories are lightweight compared to use cases. To make user stories more specific and descriptive for the development team, acceptance criteria should be defined for each user story. Acceptance criteria should also include nonfunctional requirements and business rules associated with each user story.
Some of the acceptance criteria defined for the CEC mobile application project were as follows:
Do We Still Need Business Analysts in Agile Projects?
User stories are defined and prioritized on the product backlog by a business unit representative (product owner). He or she is the voice of the customer. In theoretical formulation there is no need for business analysts or their detailed requirements documents because the product owner and the agile development team, which consists of developers and QA (quality assurance) specialists, work together at the same location under the coordination of a scrum master.
However, in practice there are some difficulties in realizing this theoretical framework.
Product owners (lacking technical knowledge) have difficulties in speaking the same language with technical teams (with limited or no business knowledge). This makes it harder to translate business needs into requirements.
Additionally, product owners can rarely spend enough time with the agile team during their own department’s busy times, and this makes the situation even more difficult.
To prevent these problems, business analysts have started to play the product owner role or have been involved in the technical team that used to be composed of only developers and QA specialists.
Whether it is waterfall or agile methodology, the following best practices should be applied in requirements documentation to prevent waste and ensure the best communication among project stakeholders:
Lean Principle of “Just Enough”
One of the main goals of the lean approach is eliminating waste by reducing work-in-process inventory (WIP). At PDLC unnecessarily long analysis and design documents represent WIP. To minimize WIP and eliminate waste, analysis and design documents should be “just enough.” They should be concise without information overload. They should include only what is absolutely necessary.
As expressed in the phrase “A picture is worth a thousand words,” business analysis diagrams, such as use case diagrams, flow charts, and context diagrams, should be used to decrease the information overload on requirements documents.
At the requirements documentation phase, the objective should not be to produce fancy documents and elegant diagrams that won’t be read by any person other
than the business analyst who prepared it. Instead, the objective should be to create products that best meet the business and customer needs by using requirements documents and diagrams as tools.
We need requirements documents during the project to translate business and customer needs into requirements for developers’ best understanding, and after the project to use as a requirements repository during future enhancement/modification of products.
The detail level of documents should be calibrated according to specific project needs and conditions as to best satisfy the above objectives.
If the detail level of the documents is too low, there is a risk of incomplete requirements definition. In this case technical teams have to guess about product features. They build products that miss critical requirements, and this triggers a vicious cycle of CRs (change requests). And sometimes they build in extra features that are not included in the requirements documents, thinking that customers will be delighted to see them. This situation is called “gold plating.” Both CRs and gold plating are factors that result in scope creep and thus waste during the project.
In daily life there would be chaos if there were no governing rules. For example, although traffic lights seem to slow us down, traffic would be locked without them. Requirement documents are like the traffic lights in big cities. If we don’t use them, the project starts fast but is locked at some later stage. However, in small cities we don’t need to locate traffic lights everywhere. Similarly, in small- scale projects we don’t have to use very detailed requirements documents.
When team members are at discrete locations, this may limit the collaboration among project stakeholders. The same problem may be observed on outsourced projects. In these situations, the detail level of documents should be increased to ensure clarity and correctness of requirements.
The documents prepared during the analysis and design phase of the project also serve as a requirements repository. This makes the deployment of future product enhancements and modifications much easier and faster. Thus requirement documents should be kept updated even after the project to serve as a repository of requirements when needed during future modifications of the products. This will save a lot of time for the project team responsible for later enhancement/modification work and prevent a considerable amount of waste in
the future.
Lean Principle of “Just in Time”
At PDLC,
-the answer of the “technically how” question (system requirements) depends on the answer of
-the “how” question (nonfunctional requirements and business rules), which depends on the answer of
-the “what” question (user requirements, functional requirements), which depends on the answer of
-the “why” question (business requirements).
According to the “Just in Time” principle in the lean approach, these questions should be answered in order and should be defined on separate documents.
First, the business requirements and user requirements should be defined and listed on business-case or vision and scope documents; then functional requirements, nonfunctional requirements, and business rules should be documented on use case documents or user stories, depending on the selected methodology. Then system requirements should be documented on technical design documents. Defining them in a single requirements document will create a lot of complexity and confusion for business units and technical teams.
