Modern methods of describing functional requirements for the system n (Writing Effective Use Cases) (Category Software)
While preparing materials for your website by System Design (https://system-design.space/) I came across a book by Alistair Cockburn in his library about writing functional requirements. Alistair is one of the co-authors of the Agile Manifesto. 2001 year and one of the main popularizers of the method of use cases (Use Cases) to describe the requirements. This year's most important book has come true. 25 So I decided to think about it, and at the same time about the evolution of approaches to the description of requirements.
At the end 1990Use cases have become one of the main ways to describe the requirements for the behavior of the system. However, writing a really good use case was not easy – it required clear wording and a logical structure, like writing a good essay. Coburn solved this problem in practice by releasing his handbook on writing use cases in 2001 year. The book explained in detail how to document scenarios: how to define the boundaries of the system (scope)Describe the actors, their goals and step-by-step interaction. The author included real-world examples and formulated a number of rules to help create clear and useful descriptions. This approach made the book popular among engineers.
At the moment, the development industry has changed significantly. With the advent of Agile commands, cumbersome requirements specifications gave way to lighter artifacts such as user stories. (user stories). Formal use cases are considered obsolete by many. However, in practice, use cases are still used, especially in large complex projects. Their structured format with the elaboration of logic and exceptions gives developers a clear technical task. Preparing a use case is more time-consuming, but later saves time on the implementation and debugging of requirements.
If we talk about the evolution of approaches, then since the release of Alistair’s book, other, more flexible methods have appeared, focused on working with user requirements.
1️⃣ User Story
A user story is a short, informal explanation of a software feature, written from the perspective of the end user. This format originated in Agile-development: requirements are formulated briefly on behalf of the user. (“As a ..., I want ..., so that ...”). User stories emphasize value to the user and, thanks to simplicity, quickly gained popularity in agile development.
2️⃣ Jobs to be Done (JTBD)
Jobs to be Done is a framework that helps product teams understand what job a customer is hiring a product to do — what problem, challenge, or opportunity is so important to them that they're willing to hire your product to address it. JTBD is a concept that considers what “work” a user “hires” a product to perform to solve their problem.
3️⃣ Job Story
An exciting alternative for some teams is the job story. A job story is focused less on the user performing some function than on the job to be done by that story. The job story format was developed as an extension of the Jobs to be Done approach. In the job story, the emphasis is shifted from the image of the user to the task itself and the context of its implementation. A template is used: "When"[situation], I want to [action], so I can [result]. This approach clearly indicates the situation and motivation, allowing you to focus on solving the real problem.
4️⃣ Design Thinking
Design thinking is a problem-solving approach that focuses on understanding users’ needs and creating innovative solutions. Design thinking (design thinking) Human-centered creative problem-solving: Through empathy and experimentation, the team seeks out-of-the-box solutions that meet users’ needs.
In general, Alistair’s book is now outdated, but the very approach to writing use cases is useful to know, especially as precursors to the next fashion approaches that play out similar ideas by cosmetically changing the wording:)
#Software #Architect #SystemDesign #SoftwareArchitecture #Processes