Requirements Engineering and the Agile Approach

With the evolution of Project Management (PM) methodology, Requirements Engineering (PE) has experienced huge change, especially when Agile is adopted by projects increasingly. However, no matter how the PM approach develops, the importance of PE is unshakable.

Based on the Qualitative Research Approach, three articles has been viewed to introduce requirements issues regarding requirement elicitation,  consensus, prioritization, user story.

In the first article, the author introduced concepts of traditional RE and some changes in Agile approach.  The second article demonstrates criteria of how to build qualified user stories. Ten requirement prioritization methods are compared in the third paper.

These three articles are sound fundamentals for readers to gain basic skill for requirement management.

Requirements Engineering and Agile Software Development

This article discusses the difference and similarities between traditional Requirements Engineering (RE) and agile approaches.

RE is a process comprising Requirements Elicitation, Requirements Analysis, Requirements Documentation, Requirements Validation, and Requirements Management. RE have a high dependency on documents for communications and the manner of prediction of future needs often leads to over documentation. (Paetsch F., Eberlein A., &Maurer F., 2003)

During Requirements Elicitation, approaches concerning the closed or open interviews of stakeholders, use cases and scenarios, observation and social analysis, focus group, brainstorming, and prototyping are often conducted during the period of the Requirement Elicitations. Based on this phase, in phase Requirements Analysis, information gathered is checked prioritized regarding necessity, consensus, completeness, consistency, and feasibility. Requirements are discussed by stakeholders and developers before write them down in requirement documents which are verified to be acceptable to organizational standards and organizational knowledge. (Paetsch F., Eberlein A., &Maurer F., 2003)

By contrast, the Agile approach is preparing to cater to continuous requirement changing and close collaboration so much that it has been adjusted to deliver upgraded products frequently. The mission of Agile determines that it cannot precisely follow the standards of RE. In fact, Agile never prepare to include a formal RE process: people cannot clearly separate a phase regarding Requirements Elicitation or Requirements Analysis from Agile process. Whereas, most RM methodologies are embedded into the Agile process: such as elicitation methods concerning interviews, brainstorming, and prioritization are also adopted in Planning Game – a phase designed in Extreme Programming(XP). (Paetsch F., Eberlein A., &Maurer F., 2003)

It is highlighted that requirement document is both essential for RE and Agile. However, Agile, as the lazy approach, do only the “right thing” by eliciting, analyzing, validating, and documenting only when needed (Paetsch F., Eberlein A., &Maurer F., 2003).

Improving Agile requirements: the Quality User Story framework and tool

This article introduces the concept of User Story and thirteen items of criteria towards creating Quality User Stories (QUS). Basing on the introduction, a software tool called Automatic Quality User Story Artisan (AQUSA) is introduced and its function has been assessed too.

According to (Lucassen, G., Dalpiaz, F., van der Werf, Jan Martijn, E. M., & Brinkkemper, S., 2016), “User stories are a concise notation for expressing requirements that are increasingly employed n agile requirements engineering and in agile development.” As explanations of requirements, user stories are used to discuss ideas with stakeholders and also act as criteria for acceptance. A user story should be able to state who it is for, what it does, and optionally why does that. Thus, an accepted user story format is “As a, <type of user/role>, I want <goal/mean>, [so that, some reason/end].” Whereas in Scrum – a specific Agile pattern, Epic and Themes also involved into user story design with the former one identifies a list of smaller, implementable user stories and the later one defines a set of user stories who are in the same criterion such as authorization.

To qualify a user story, thirteen criteria are separated into three categories regarding Syntactic, Semantic, and Pragmatic. Those standards are used to guideline the creation of user stories and aim to make user stories clearly defined, focus on a single feature, able to be estimated, etc. The article also gives out a table of ill-defined user stories to explain what regulation is broken. Such as “I want to see an error when I cannot see recommendations after I upload an article,” this user story breaks the law of “well-formed” since the role is missing in the story. (Lucassen, G., Dalpiaz, F., van der Werf, Jan Martijn, E. M., & Brinkkemper, S., 2016)

User stories inside a specific user story set must be unique without confliction (no similar stories can exist in one set, the scope of work items must be consistent), uniform (most stories in the set use same format), independent (stories must not rely on the implementation of another case), and complete (a story cannot use an undefined term without reference. the undefined term or dependency should be stated in terms of relationship). (Lucassen, G., Dalpiaz, F., van der Werf, Jan Martijn, E. M., & Brinkkemper, S., 2016)

Both those 13 single-user-story criteria and four user-story-set criteria are guideline for agile project engineer to follow when they want to create agile requirements in high quality.

Comparison of Requirement Prioritization Techniques to Find Best Prioritization Technique

This article introduces ten techniques for requirement prioritization and compares them to find the best method.

Some methods are using grouping approach by assign requirements with different group level then those requirements in the same group will be in the same priority. One of the famous grouping methodologies is Museum of Soviet Calculators on the Web (MoScoW) who provides four prioritization groups concerning MUST have, SHOULD have, COULD have, and WONT have. Based on the research result demonstrated in this article, grouping approaches feature low effort, low difficulty, consistent, and high confidence from the users. Especially, MoScoW can help to handle a large number of changes. (Javed, A. K., Rehman, I. U., Yawar, H. K., Iftikhar, J. K., & Rashid, S., 2015)

Bubble Sort, Minimal Spanning Tree, and Binary Search Tree provide methods for sorting requirements into a requirements list from the most important requirement down to the least important one. When these approaches are adopted, stakeholders and software engineers should be able to compare requirements pair by pair then adjust the location of their importance one by one until all requirement have been put into the correct position. The sorting approach needs the most number of decisions although this method is easy to use. (Javed, A. K., Rehman, I. U., Yawar, H. K., Iftikhar, J. K., & Rashid, S., 2015)

Hundred Dollar Method and Analytic Hierarchy Process (AHP) are typical methods using ratio to identify priorities of requirements. During these processes, stakeholders should either balance importance among several requirements or mark out between requirements to what extent one is important than the other. AHP is considered to be the most reliable approach for its fault tolerance, consistency, ratio feature. However, to get the final results, AHP needs the most effort regarding decision making and time-consuming. (Javed, A. K., Rehman, I. U., Yawar, H. K., Iftikhar, J. K., & Rashid, S., 2015)

Requirements are the baseline for specific IT product or service since they define what the product/service is, regulate development scope, provide background for discussion and negotiation between stakeholders and project engineers, and most importantly, act as a guideline for newly hired engineers to understand the product/service. Thus, requirements management are essential for all kind of IT project. To elicit requirements, interview, brainstorming, and observation is often adopted. While to reach consensus, negotiation and team-decision are often valuable to be considered. (Paetsch F., Eberlein A., &Maurer F., 2003)

However, Traditional RE approaches cannot fulfill the current project management approaches. With more and more project adopt Agile methodology, engineers use user stories to replace traditional requirement document, and the way they elicit requirement has also changed: they document what exactly needed only when needed; more collaborations are involved whenever they need, but they only discuss what are needed; traditional requirements tend to explain what customer need or want while user story focuses on interaction between role and object – user to machine, user to user, machine to user, machine to machine. (Paetsch F., Eberlein A., &Maurer F., 2003)

Since user stories are as important as traditional requirement document, the quality of user stories become equally important. To define high qualifies user stories, a set of guideline consisting of 13 criteria concerning syntactic, semantic, and pragmatic are required to adopt. (Lucassen, G., Dalpiaz, F., van der Werf, Jan Martijn, E. M., & Brinkkemper, S., 2016)

Before start iterations or springs, choosing specific requirements or user stories out of the whole repository on the basis of requirement prioritization technology is a must. To mark priority of each requirement or just sort them in order, the customers must make most of the decisions such as a case is a must or just what they want. Project engineers also need to estimate time effort and provide to what extent they think the estimation is accurate or not (risk aspect). Sometimes, stakeholders are asked to group these requirements (grouping requirements) or to vote 100 dollars to several requirements(buy requirements).  Some prioritization methods are easy to use and reasonably accurate (MoScoW) while some are the most reliable but very difficult to use regarding (AHP). (Javed, A. K., Rehman, I. U., Yawar, H. K., Iftikhar, J. K., & Rashid, S., 2015)

Requirements: conditions or capabilities that must be met by the project or present in the product, service, or result to satisfy an agreement or other formally imposed specification

Requirements engineering (RE): is a traditional software engineering process with the goal to identify, analyze, document and validate requirements for the system to be developed.

Requirements Prioritization: to deliver the most valuable feathers as early as possible under a tight schedule, limited resources, and high customer expectations, the customer should decide which requirements are more urgent than others to be implemented.

Javed, A. K., Rehman, I. U., Yawar, H. K., Iftikhar, J. K., & Rashid, S. (2015). Comparison of requirement prioritization techniques to find best prioritization technique. International Journal of Modern Education and Computer Science,7(11), 53-59. doi:http://dx.doi.org/10.5815/ijmecs.2015.11.06

Abstract:

This paper describes an assessment of different requirement prioritization techniques (binary search tree, AHP, hierarchy AHP, spanning tree matrix, priority group/Numerical Analysis, bubble sort, MoSoW, simple ranking and Planning Game) on the basis of previous literature. Five research papers and thesis are critically reviewed, in order to select best requirement prioritization method. The study of literature shows that AHP is the best requirements prioritization technique amongst all the requirements prioritization techniques. It provides the most efficient and reliable results which are on ratio scale. It is fault- tolerant and provides a consistency check.

Lucassen, G., Dalpiaz, F., van der Werf, Jan Martijn, E. M., & Brinkkemper, S. (2016). Improving agile requirements: The quality user story framework and tool. Requirements Engineering. 21(3), 383-403. doi:http://dx.doi.org/10.1007/s00766-016-0250-x

Abstract:

User stories are a widely adopted requirements notation in agile development. Yet, user stories are too often poorly written in practice and exhibit inherent quality defects. Triggered by this observation, we propose the Quality User Story (QUS) framework, a set of 13 quality criteria that user story writers should strive to conform to. Based on QUS, we present the Automatic Quality User Story Artisan (AQUSA) software tool. Relying on natural language processing (NLP) techniques, AQUSA detects quality defects and suggest possible remedies. We describe the architecture of AQUSA, its implementation, and we report on an evaluation that analyzes 1023 user stories obtained from 18 software companies. Our tool does not yet reach the ambitious 100 % recall that Daniel Berry and colleagues require NLP tools for RE to achieve. However, we obtain promising results and we identify some improvements that will substantially improve recall and precision.

Paetsch F., Eberlein A., &Maurer F. (2003). Requirements engineering and agile software development. International workshop on enabling technologies: infrastructure for collaborative enterprises,IEEE.308-313. doi: 10.1109/ENABL.2003.1231428

Abstract:

This article compares traditional requirements engineering approaches and agile software development. Our paper analyzes commonalities and differences of both approaches and determines possible ways how agile software development can benefit from requirements engineering methods.