In this blog post, By Scott Sehlhorst starts with a simple fact: if there is a lot of discussions on how to write requirements, there is not so much material on why to write requirements. His advice is that you should start by thinking about why you write requirements before you decide how to write your requirements.
Scott Sehlhorst provides the following reasons to write requirements
* Improve your understanding of what your market needs (from you).
* Decide on the sequence in which you will deliver what you choose to build.
* Collaborate with (and set expectations for) your engineering team.
* Manage expectations with your stakeholders.
* Improve the efficiency of your product-creation process.
* Remember why your team created what they created.
Each of these reasons is detailled in the post. The conclusion is that we should “keep in mind why we write requirements. When considering how you will write requirements, think about the impact of different techniques on the goals that matter to you.”
Modern software development approaches like Agile and Scrum support a strong collaboration between all member of the software development team, software testers and business analysts included. Even if you don’t use a method like Behavior-Driven Development (BDD) or Specification by Example, checking the fact that you will be able to actually test your requirements is […]
User stories are a technique taken from the agile development playbook that can easily be applied in traditional systems development and maintenance. User stories help you document needs in a structured way, from the users’ perspective. They’re a good basis for test cases, so as to support integrated requirements management and testing. In this article, […]
This article is an extract of the “Complete Systems Analysis” written by James and Suzanne Robertson. It explains the basics of analysis models and emphasize that the important thing to remember is that modeling tools are complementary. Each shows one aspect of the system. Together, they make a complete working model of the system.