Some years ago, we used to write use cases, which have been renamed as user stories in the last few years. However, the names are not the key to success here, and it makes no difference whether you are using old-fashioned methods (such as the Ration Unified Process (RUP) or the most cutting-edge frameworks (such as Scrum) to build your projects. Understanding the domain of the business and owning a product will allow teams to develop successful projects.
As you probably know, RUP is a software development framework that defines a set of phases and has a tremendous amount of documentation associated with each stage. The idea here is to determine what artifacts to generate at each stage. This task is tedious, and teams have often ended up defining a large quantity of useless and time-consuming documentation, without providing any added value to the product. As an alternative to creating documentation, we will discuss the C4 model later in this chapter.
Over time, many books have been written to explain how to manage user requirements. Two of these include Writing Effective Use Cases by Alistair Cockburn and User Stories Applied by Mike Cohn. These books are the most relevant, and you should consider reading them and making them a part of your library, in order to use them as a reference source whenever necessary.
An efficient process for gathering user requirements should be a part of the vision and the goals that the project should accomplish. Having brainstorming meetings with as many people involved in the project as possible is beneficial for allowing the team in charge of the software implementation to distinguish between the Minimum Viable Product (MVP) and the desired and expendable features that will be implemented as part of a new release once the MVP version has been accomplished.
Understanding the MVP for the software under construction is paramount; it should give you the minimum features possible to satisfy the user requirements. Once these features are identified, it is also necessary to define the acceptance criteria for them. The products built from here will be used as the base for retrieving feedback from the business people (in order to correct any misconceptions) and also to add new features (in order to grow the solution).
Today, we also count on bug tracking systems to write user requirements as tickets with different classifications, such as bugs, user stories, and spikes, among others. These tickets are used to gain a better understanding of how long a feature takes to be implemented, and how many bugs are involved in it.
Dealing with business requirements in this way gives us useful information that can be analyzed later, in order to improve the performance of a team, as well as the way it is organized. There are a bunch of explanations of how to manage tickets, but if you want a better idea of the principles of bug tracking, I encourage you to read a useful article written by Yegor Bugayenko, which is available at http://www.yegor256.com/2014/11/24/principles-of-bug-tracking.html.