1. Requirements Engineering Requirements Engineering in Agile Methods Lecture-28

2. Recap 2  How traceability information is used in change impact analysis?  Impact on time  Impact on cost  Requirement engineering in agile methods

3. Today’s lecture 3  Requirement engineering for agile methods

4. The Agile Manifesto  Manifesto includes following points:  Individuals and Interactions over Process and Tools  Customer Collaboration over Contracts  Working Software over Documentation  Responding to Change over Planning  From such values, a set of common practices and behaviors are identifies.  Adaptability  Incremental Development  Frequent Releases  Requirements Prioritization Before Every Iteration  High Customer Involvement

5. Team Size in Agile Methods Read more: http://www.devx.com/architect/Article/32836/0/page/2

6. Agile Approaches to Requirements Engineering  The Customer  In AMs, the customer assumes a vital role. Usually, the term “customer” identifies a set of stakeholders that belongs to the organization that is paying for the development of a software product.  In the case of mass-products for which there are no organizations paying directly for the product, the development team has to identify an expert in the area (e.g., a marketing expert) that is able to act as the customer and participate in the development of the product.  This approach is feasible only if the size of the problem is limited and a single person can act as customer, representing all the stakeholders.

7. Agile Approaches to Requirements Engineering  The customer-on-site practice defines some specific requirements for the customer:  Availability:  The customer has to be always available to answer questions coming from the development team. Any delay in the answer delays the development of the product.  Complete Knowledge:  The customer is the representative for all the stakeholders. Therefore, he is able to answer all questions, since he is the domain expert and knows how the application should work and the input/output data required. Again, this is possible if the size of the project is limited.  Decision Power:  The customer is able to make final decisions and commitments. Changes in requirements, acceptance of the features implemented, etc. can be decided directly by the customer, allowing a fast decision making process.

8. Agile Approaches to Requirements Engineering  Waste in Requirements  AMs focus on the identification and reduction of waste in the development process.  Requirements engineering in AMs focuses on:  Reduction of waste from requirements  Managing the requirements evolution

9. Agile Approaches to Requirements Engineering  The main effects of waste in this area include:  More source code to write and higher cost  Increased complexity of the source code  Delayed delivery of the final version of the application with all functionalities  More complex and costly maintenance  More resources required by the application, including: memory usage, processing power, network usage, etc  Increased complexity of the application from the point of view of the customer (e.g., more complex user interface, more effort to learn how to use the application, etc.)  Savings produced by the application in the production process of the customer are delayed

10. Agile Approaches to Requirements Engineering  In order to reduce the probability of such misunderstanding, AMs adopt several techniques focused on the interaction between the customer and the development team:  The whole Development Team Collects Requirements from the Customer  Requirements are Collected using a Common Language  Direct Interaction Between the Development Team and the Customer  Requirements Splitting  Waste Management  Requirements Prioritization  Incremental Releases

11. Requirements Evolution  AMs base the requirements collection and management on three main hypotheses:  Requirements are not well known at the beginning of the project  Requirements change  Making changes is not expensive

12. Requirements Evolution  Managing variability is a challenge that AMs approach in two ways:  Decoupling Requirements  Requirements Prioritization

13. Non-Functional Requirements  AMs do not provide any widely accepted technique for eliciting and managing non-functional requirements.  The need of specifying non-functional requirements is less important than in other context due to the continuous interaction with the customer.  After every iteration, the product is released and the customer is able to test the product.  If he identifies problems related to non-functional qualities, the team can adapt the system to meet such requirements in the subsequent iteration without affecting the schedule too much.

14. Roles and Responsibilities  The Customer  The customer’s presence is extremely important in AMs, since the amount of documentation is reduced to the minimum and the development team often asks for clarification regarding requirements.  Developers  They have to be very good developers, be able to work in teams, and interact with the customer using his/her own language.  Managers  In AMs, managers have to create and sustain a framework for the establishment of a productive interaction between the development team and the customer.  They can achieve this goal identifying the best people to be included in an agile team, promoting collaboration, and negotiating contracts with the customer.

15. Agile process models  Extreme Programming (XP)  Adaptive Software Development  Scrum  Dynamic System Development Method (DSDM)  Crystal  Feature Driven Development  Agile Modeling (AM)

16. Extreme Programming (XP)  Perhaps the best-known and most widely used agile method.  Extreme Programming (XP) takes an ‘extreme’ approach to iterative development.  New versions may be built several times per day;  Increments are delivered to customers every 2 weeks;  All tests must be run for every build and the build is only accepted if tests run successfully.  XP Values  Communication  Simplicity  Feedback  Courage  Respect

17. Extreme Programming (XP)

18.  XP Planning  Begins with the creation of user stories  Agile team assesses each story and assigns a cost  Stories are grouped to for a deliverable increment  A commitment is made on delivery date  After the first increment project velocity is used to help define subsequent delivery dates for other increments

19. Extreme Programming (XP)  XP Design  Follows the KIS (keep it simple) principle  Encourage the use of CRC (class-responsibility-cards) cards  For difficult design problems, suggests the creation of spike solutions — a design prototype  Encourages refactoring — an iterative refinement of the internal program design  XP Coding  Recommends the construction of a unit test for a store before coding commences  Encourages pair programming  XP Testing  All unit tests are executed daily  Acceptance tests are defined by the customer and executed to assess customer visible functionality

20. XP and agile principles  Incremental development is supported through small, frequent system releases.  Customer involvement means full-time customer engagement with the team.  People not process through pair programming, collective ownership and a process that avoids long working hours.  Change supported through regular system releases.  Maintaining simplicity through constant refactoring of code.

21. Summary 21  Requirement engineering in AMs

22. Customer involvement  Customer involvement is a key part of XP where the customer is part of the development team.  The role of the customer is:  To help develop stories that define the requirements  To help prioritize the features to be implemented in each release  To help develop acceptance tests which assess whether or not the system meets its requirements.

23. Requirements scenarios  In XP, user requirements are expressed as scenarios or user stories.  These are written on cards and the development team break them down into implementation tasks. These tasks are the basis of schedule and cost estimates.  The customer chooses the stories for inclusion in the next release based on their priorities and the schedule estimates.

24. Story card for document downloading

25. XP and change  Conventional wisdom in software engineering is to design for change. It is worth spending time and effort anticipating changes as this reduces costs later in the life cycle.  XP, however, maintains that this is not worthwhile as changes cannot be reliably anticipated.  Rather, it proposes constant code improvement (refactoring) to make changes easier when they have to be implemented.

26. Refactoring  Refactoring is the process of code improvement where code is reorganised and rewritten to make it more efficient, easier to understand, etc.  Refactoring is required because frequent releases mean that code is developed incrementally and therefore tends to become messy.  Refactoring should not change the functionality of the system.  Automated testing simplifies refactoring as you can see if the changed code still runs the tests successfully.

27. Testing in XP  Test-first development.  Incremental test development from scenarios.  User involvement in test development and validation.  Automated test harnesses are used to run all component tests each time that a new release is built.

28. Task cards for document downloading

29. Test case description

30. Test-first development  Writing tests before code clarifies the requirements to be implemented.  Tests are written as programs rather than data so that they can be executed automatically. The test includes a check that it has executed correctly.  All previous and new tests are automatically run when new functionality is added. Thus checking that the new functionality has not introduced errors.

31. Tools for Requirements Management in AMs  UML Modeling Tools  Requirements Negotiation Tools  Instant Messaging Tools  Project Management Tools