There is an evolution going on in testing. It used to be that testing was about confirming to the specification. Testers were often brought in too late and had too little influence, but that is changing now as Cirilio Wortel explained in his talk on the evolution of software testing.
Behaviour-Driven Development (BDD) can help in overcoming the gap between the developer’s understanding of what needs to be built and the business’ understanding of the technical challenges caused by the requirements. The reason is improvement in communication between the two groups, Alistair Stead and Konstantin Kudryashov explains in their Beginner’s guide to BDD.
At the recent Project Management Institute Global Congress the Business Analysis Practice Guide was announced, to complement the Professional in Business Analysis certification which was launched in November. InfoQ spoke to Dave Bieg, Business Analysis and Requirements Program Manager about the certification and the practice guide.
To incrementally develop and deliver products using agile software development, requirements are gathered and organized into a product backlog. A requirement technique that is used in agile software development is use cases. Some techniques to apply use cases for managing product requirements in agile are use case 2.0, slicing and laminating.
The goal of a software project is to deliver value to stakeholders and Behaviour-Driven Development, (BDD), is designed for that, Viktor Farcic, a software developer working on transitions from waterfall to agile processes, states in the first of four blog posts describing his view on BDD.
Visure Solutions recently announced the availability of IRQA which denotes a solution for requirements definition and management (RDM). A sound process using professional tools is important for ensuring the quality of product and solution development with respect to the requirements specification.
On October 26th, The Jolt Judges announced the awards for 2011 in the category “Design, Planning, and Architecture Tools”. In detail, the Jolt hall of fame now includes the products Paradigm for UML, Restructure 101, and Requirements Center 2010.
Team Foundation Server 11 has added many features in the area of Application Lifecycle Management. Some of the highlights include support for code reviews, iterations/sprints, resource allocation, third part testing frameworks, and a much more capable dependency graph.
Recently, a proposal for the Requirements Modeling Framework (RMF) has been officially released by eclipse.org. Vision is to have at least one clean-room implementation of the OMG ReqIF standard in form of an EMF model and some rudimentary tooling to edit these models.
Non-Functional requirements are often associated with the state of the system and not with the functionality that the system has to offer. General 'ilities' of the system such as scalability, interoperability, maintainability, portability, performance and security fall under this umbrella. Agile teams usually struggle with defining and estimating the non-functional requirements in their projects.
Software Architecture is one of the important topics for software engineers, because many failures of software development projects are caused by inadequate design. Thus, it is essential to learn more about architectural issues in theory and practice. Interesting new books that have been published recently or in the near future could be very helpful
Mike Burrows started a discussion on the Kanbandev group which has led the community to explore the Expand / Collapse pattern. The discussion was covered elsewhere on InfoQ, in an article which followed the viewpoints of many practitioners who see more value in expansion than collapse. However, many people found both aspects of the pattern useful.
Agile methods recommend decomposing ("expanding") features into many small user stories. After the code has been written, however, should we collapse these small stories back into the original feature so we can deal with them all as a unit? Are there any advantages in doing that collapse, and if so, what are they?
In Scrum, requirements are commonly expressed as user stories. But is it OK to also make use of use cases in Scrum? And, if so, under what circumstances should you do so?
A Computerworld article and webinar announcement, both featuring the use of iRise, to visually capture business application requirements calls attention to this growing product segment.