Content in the Knowledge category
Modern software development approaches like Agile 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 or Specification by Example, checking the fact that you will be able to actually test your requirements is a good thing. In his article, Richard Ellison share some best practices to reviewing requirements for testability from the point of view of a software tester.
Techne is an abstract requirements modeling language that lays formal foundations for new modeling languages applicable during early phases of the requirements engineering process. During these phases, the requirements problem for the system-to-be is being structured, its candidate solutions described and compared in terms of how desirable they are to stakeholders.
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, you’ll find concrete advice based on our own experiences developing the requirements and testing tool ReQtest for how you can make user stories the basis for requirements management and testing.
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.
This blog post by Betsy Stockdale explains how to use the Feature Tree model to discover missing requirements.
In this blog post, James Christie starts from the fact that perfect requirements don’t exist to discuss the idea that the quality of requirements is directly influenced by the time and money you invest in crafting them.
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.
In this article, Trent Wong discusses how well the Business Analyst’s role is defined in organization. He starts by saying that the Business Analyst is a key success factor for software development projects. You need him to getting the requirements list properly, effectively communicating them to management and translating the requirements so the developers can build the application.
There is no business analyst role in the Scrum Agile project management framework. Based on this fact and some perceptions about Agile, Roland Hesz tries to answer the questions “Do we need a business analyst on an agile project? Are there Agile business analysts?”.
Agile uses mostly user stories to capture requirements. In his blog post, Jean-Jacques Dubray explains that there is a problem with user stories because they tend to focus on the solution and not on the problem definition.