What do you document and how much should you document? This question is often present in software development projects and even more now with Agile approaches. This article presents a template for managing software requirements and software problems. This templates have been validated within the industry in various parts of the world.

There are different popular models for collaborative software requirements definition. In this article, Gojko Adzic, the author of Specification by Example, discusses some of them. Big specification workshops, like Product Backlog Refinement (PBR) workshops, with the entire team allows building a shared understanding and produce a set of examples that illustrate a feature. Smaller workshops that involve one developer, one tester, and one business analyst are called Three Amigos meeting. Teams where business users and stakeholders sit close by (and are readily available to answer questions) have great results with …

A user story is a high-level requirement of a feature provided from the perspective of a stakeholder. A comprehensive user story has acceptance criteria that cover all possible functional scenarios or conditions needed to satisfy the user requirements. In development and testing terms, this means defining positive and negative scenarios. This article defines what differs between the normal user stories and the comprehensive user stories.

Certification has become a mainstream feature of professional careers. Various business analysis and software requirements organizations exists that offers both a community for sharing knowledge and certifications opportunities in a similar way than the Project Management Institute provides for project management domain. This article presents a list of business analysis and software requirements certifications currently available from different professional organizations.

Software Product Line (SPL) core assets development is an effective approach in software reuse in which core assets can be shared among the members of the product line with an explicit treatment of variability. This article propose an approach for transitioning requirements models to architecture levels to overcome the issue of variability at the requirements level in software product line context. In order to address the issues of integrating functional, non-functional, architecture and
design decisions in relating between the two abstractions levels, we argue that software product line architecture design method …

User stories are well established in agile software development processes, but they should not be seen as detailed requirements specifications. It is accepted that the end users do not know all the requirements at once. Therefore, user stories only give hints about the expectations of an end user. A computer supported strategy is proposed to get more details in a communications process. This strategy focuses on the agile development of information systems. Namely, it is proposed that additional information, not found in a user story, is extracted from natural language …

People often believe that Agile software development requires not documentation. Even if the Agile Manifesto values “Working Software over Comprehensive Documentation”, you should note the word “over” in this statement. The Manifesto is not recommending no documentation, but stating a preference for working software over documentation.

In Scrum user stories are the starting point of a conversation. This articles discusses the challenge for the Product Owner to provide acceptance criteria to help the Scrum team understand user stories. The author explains that acceptance criteria need not constitute an exhaustive list, but they should be sufficient to move forward. Acceptance criteria are temporal in nature, because they are the functionality the product owner had in mind at a distant time in the past. Acceptance criteria become refined with sprint progress through each story iteration. Acceptance criteria can …

This article provides a methodological approach that focuses on requirements engineering within the Model-Driven Development (MDD) context. Our approach is an OpenUP extension in which the requirements discipline is placed in the model-driven context. We believe that the integration of requirements engineering and MDD into one consistent process will provide practitioners with the benefits of both. This paper presents the definition of the proposed process, OpenUP/MDRE, including its activities, roles, and work products. We also provide an example of its use in a SOA-based software development project. The use of …

This article discusses the three dimensions of user stories: the backlog order, the complexity (or effort) and the business value. These dimensions are flexible until the sprint commitment, but right before it, you should have estimated the complexity and the business value for the top of the product backlog, which means that the product backlog has been re-ordered. The sprint commitment can then occur: the team pulls the stories from the top of the product backlog into the sprint backlog, negotiate the order and amount with the PO. After the …