1

BIG REQUIREMENT UP FRONT (BRUF) AT A GLANCE

AGILE REQUIREMENTS
A CUSTOMER TRANSPARENT PROCESS
Mahmoud Mostafa Hosny Software Engineering Department Nile University Smart Village, Egypt Mahmoud.Hosny@nileu.edu.eg

ABSTRACT
The rise of agile development processes has changed requirements as much as any other part of development. Agile-based principles are more open to adding and refining requirements later in the development process and to having as thin a level of document detail as possible and a less detail than was common in requirements gathering for traditional software processes. The agile approach to software requirements embraces change, flexibility and face-to-face communication in a just-in-time manner. This method can help bridge the communications gap between developers and users that has been a longstanding pain point in software projects.

Many traditional project teams run into trouble when they try to define all of the requirements up front, often the result of a misguided idea that developers will actually read and follow what the requirements document contains. The reality is that the requirements document is usually insufficient, regardless of how much effort goes into it, the requirements change anyway, and the developers eventually end up going directly to their stakeholders for information anyway (or they simply guess what their stakeholders meant). Agilest know that if they have the ability to elicit detailed requirements up front then they can also do the same when they actually need the information. They also know that any investment in detailed documentation early in the project will be wasted when the requirements inevitably change. Agilest choose to not waste time early in the project writing detailed requirements documents because they know that this is a very poor way to work. [1]

OLD TRADITIONAL WAYS

The first principal of agile software development is that the highest priority is to satisfy the customer through early and continuous delivery of valuable software. This is a significant departure from traditional waterfall methods in which delivery of working software happens not early, but very late in the process [figure 1]. The customer will not see any business value software before months of working. In waterfall type methods, the focus of the work early in the process is on understanding and documenting what the software product should do. [2] All of the requirements are gathered up front at the beginning of the development cycle, with no analyst or customer involvement after that, all of the design is completed next, and finally the master design is implemented into production quality software. [3]

Mahmoud Mostafa Hosny Agile Requirements: A Customer Transparent Process

FIGURE 1: SEQUENTIAL PHASED APPROACH [ 3 ]

the project, but also it handles the risk of finding bad requirement or bugs before the project nearly completed. Agile visionary Kent Beck challenged the traditional cost of change curve [figure 2] evidenced by Barry Boehm over twenty years ago. Becks model espouses that the cost of change can be inexpensive even late in the project lifecycle while maintaining or increasing system quality. [3]

This approach holds that complex systems can be built in a single pass, without going back. [3] The cost of change in a waterfall project increases exponentially over time because the developer is forced to make any and all project decisions at the beginning of the Project .[3] Any late changes in the requirements discovered when implementing or testing the software will lead into a dramatically change in the requirement, design and implementation phase which will be very costly.

FIGURE 2: COST OF CHANGES CURVES

[3]

GOING AGILE ACCORDING TO AGILE MANIFESTO CUSTOMER SATISFACTION BY RAPID, CONTINUOUS DELIVERY OF USEFUL SOFTWARE [ 4 ]
Customers are impatient; they need to see and feel something early and not to wait for months to get a business value. Agile satisfies the customers by bringing to them a business valuable running product in each a time-boxed iteration not more than 3 or 4 weeks.

CLOSE, DAILY COOPERATION BETWEEN BUSINESS PEOPLE AND DEVELOPERS [ 4 ] FIGURE 3: PROJECT COMMUNITY
[5]

EVEN LATE CHANGES IN REQUIREMENTS ARE WELCOMED

[4]

The Ill Know it When I See It (IKIWISI) law says that software development customers can better describe what they really want after seeing and trying working, functional software.
[3]

Agile welcome late changes or refinement in requirements and it wouldnt affect the cost of Mahmoud Mostafa Hosny Agile Requirements: A Customer Transparent Process

No matter what development disciplines are required, each agile team will contain a customer representative [figure 4]. This person is appointed by stakeholders to act on their behalf and makes a personal commitment to being available for developers to answer miditeration problem-domain questions. At the end of each iteration, stakeholders and the customer representative review progress and re-evaluate priorities with a view to optimizing the return on investment and ensuring alignment with customer needs and company goals. [6]

AGILE REQIUREMENTS: A CUSTOMER TRANSPARENT PROCESS

The process is entirely transparent:
[7]

1.The customer states the goal or theme for the iteration. 2.The delivery team members state how much time they have to devote to the effort 3.The customer selects the highest-priority requirements from the backlog (the master catalog of work needed to build the product). 4.The desired requirements are further discussed and elaborated on, as needed. 5.The team estimates and tasks out the work. 6.The team and the customer explore risks and dependences.

FIGURE 4: AGILE PROJECT COMMUNITY

[5]

7.The team makes an explicit commitment about which requirements will be delivered. These Steps can be adopted by many Agile Software development Methodologies and practices Like:

SCRUM
During each sprint, typically a two to four week period (with the length being decided by the team), the team creates a potentially shippable product increment (for example, working and tested software). The set of Mahmoud Mostafa Hosny Agile Requirements: A Customer Transparent Process

4 features that go into a sprint come from the product backlog, which is a prioritized set of high level requirements of work to be done. Which backlog items go into the sprint is determined during the sprint planning meeting. During this meeting, the Product Owner informs the team of the items in the product backlog that he or she wants completed. The team then determines how much of this they can commit to complete during the next sprint. During a sprint, no one is allowed to change the sprint backlog, which means that the requirements are frozen for that sprint. After a sprint is completed, the team demonstrates the use of the software [figure 5]. [8] will commit themselves to the functionality that will be included and the date of the next release. [10]

Steering Phase: In the steering phase the

plan can be adjusted, new requirements can be added and/or existing requirements can be changed or removed. [10]

ITERATION PLANNING
This plans the activities and tasks of the developers. In this process the customer is not involved. Iteration Planning also consists of three phases: [10]

FIGURE 5: THE SCRUM PROCESS

[9]

Exploration Phase: Within this phase the

requirement will be translated to different tasks. The tasks are recorded on task cards.
[10]

Commitment Phase: The tasks will be

assigned to the programmers and the time it takes to complete will be estimated. [10]

Steering Phase: The tasks are performed

and the end result is matched with the original user story. [10]

AGILE MODELING
Agile Modeling is a practice-based methodology for modeling and documentation of software-based systems. [11] Agile Modeling is a supplement to other agile methodologies like Extreme Programming ("XP") and Scrum [figure 6]. [11]

EXTREM PROGRAMMING (XP)

The main planning process within Extreme Programming is called the Planning Game. The game is a meeting that occurs once per iteration, typically once a week. The planning process is divided into two parts: [10]

FIGURE 6: AGILE MODLING INTERACTION [ 1 ]

RELEASE PLANNING
This is focused on determining what requirements are included in which near-term releases, and when they should be delivered. The customers and developers are both part of this. Release Planning consists of three phases:

Exploration Phase: In this phase the

customer will provide a short list of high-value requirements for the system. These will be written down on user story cards. [10]

Commitment Phase: Within the

commitment phase business and developers

[Figure 7] depicts the Agile Model Driven Development (AMDD) lifecycle, which depicts how Agile Modeling (AM) is applied by agile software development teams. The critical aspects which we're concerned about right now are initial requirements modeling,

Mahmoud Mostafa Hosny Agile Requirements: A Customer Transparent Process

5 iteration modeling, and model storming. The fundamental idea is that you do just barely enough modeling at the beginning of the project to understand the requirements for your system at a high level, and then you gather the details as you need to on a just-intime (JIT) basis. [1] A domain model identifies fundamental business entity types and the relationships between then. Domain models may be depicted as a slim UML class diagram, or even a slim data model. [1]

USER INTERFACE MODEL

For user interface intensive projects you should consider developing some screen sketches. [1] What level of detail do you actually need? Practically, you need requirements artifacts which are just barely good enough to give you this understanding and no more. [1]

FIGURE 7: THE (AMDD) LIFECYCLE

[1]

ITERATION MODELING
It is a part of the iteration planning effort. It is used to model enough requirements to give good estimation of the work, and help in planning the work for the iteration. [1]

MODEL STORMING
Work through specific issues on a JIT Manner, detailed requirements are elicited, or perhaps a better way to think of it is that the high-level requirements are analyzed, on a just in time basis. This is often done by sketching on paper or a whiteboard with the stakeholders. These model storming sessions are typically impromptu events and typically last for five to ten minutes .The people get together, gather around a shared modeling tool (e.g. the whiteboard), and explore the issue until their satisfied that they understand it and then go to coding.
[1]

INITIAL REQUIREMENTS MODELING

At the beginning of a project you need to take several days to envision the high-level requirements and to understand the scope of the release (what you think the system should do). Your goal is to get a gut feel for what the project is all about, not to document in detail what you think the system should do: the documentation can come later, if you actually need it. For your initial requirements model you may need some form of: [1]

AGILE REQUIREMNT MANAGEMENT

The agile approach to managing requirements, reflecting both Extreme Programming's planning game and the Scrum methodology. Your development team has a list of prioritized requirements that need to be implemented; Extreme Programmers have a stack of user stories written on index cards. From the top of the stack, the team takes the highest-priority requirement that they believe they can implement within the current iteration. Scrum

USAGE MODEL
As example, a collection use cases or a user stories for an Extreme Programming (XP) project. [1]

INITIAL DOMAIN MODEL

Mahmoud Mostafa Hosny Agile Requirements: A Customer Transparent Process

6 suggests that developers freeze the requirements for each iteration to provide a level of stability. If you do this, any change to a requirement you're currently implementing should be treated as a new requirement [figure 8]. [12] reorganize them into smaller and more manageable artifacts. [12]

EMBRACE CHANGE, DON'T PREVENT IT

Active stakeholder participation throughout the project's lifecycle is key. Stakeholders must prioritize requirements, make decisions and provide information in a timely manner. Because they're the business experts, they should also be actively involved with any requirements and analysis modeling efforts. By embracing change and finding ways to truly manage requirements, you can deliver software that meets the needs of your users in a timely and cost-effective manner. Who can say no to that? [12]

FIGURE 8: AGILE REQUIREMENT CHANGE MANAGEMENT PROCESS

[12]

CONCLUSION
The purpose of this paper is to trace the basic aspects of requirement process in agile software development methodology and to show the simplicity and transparency of process to the Customer by involving him in each activity in the process.

SETTING PRIORITIES
New requirements, including defects identified as part of your user testing activities, are prioritized by your project stakeholders and added to the stack in the appropriate place. Your project stakeholders can define new requirements, change their minds about existing ones, and even reprioritize them as they see fit. However, they must also be responsible for making decisions and providing information in a timely manner. [12]

ACKNOWLEDGMENT
I would like to express my thanks to: Dr.Akram Salah for his valuable suggestions and continuous guidance, and for his great effort in developing my limited knowledge and background in software requirement enough to be a good core for beginning my journey in the software engineering track.

ESTIMATING REQUIREMENTS
Developers are responsible for estimating the effort required to implement the requirements that they'll work on. Although they may initially lack the requisite skills, it doesn't take long for people to hone their estimation expertise when they know that they'll have to live up to those estimates. [12] Smaller requirements are easier to estimate accurately. Shall statements, such as "The system shall convert feet to meters, are an example of very small requirements. User stories are a little larger but still relatively easy to estimate. Use cases can become too large to estimate effectively, although you can

REFERENCES
[1] Scott W. Ambler "agile modeling: Agile Requirements Modeling". [2] MJMurphy "Agile Requirements no BRUF just GRIT. [3] Victor Szalvay "paper: An Introduction to Agile Software Development". [4] Agile Manifesto principles. [5] Ahmed sidky "Fundamental of Agile Software Development". [6] Wikipedia "Agile software development". [7] Gottesdiener, Ellen "The Software Requirements Memory Jogger"

Mahmoud Mostafa Hosny Agile Requirements: A Customer Transparent Process

7
[8] Schwaber, Ken (1 February 2004). Agile Project Management with Scrum [9] ADM Inc., What is SCRUM: http://controlchaos.com, 2004 [10] Melnik, Grigori; Maurer, Frank (2004). "Introducing Agile Methods: Three Years of Experience". [11] Wikipedia "Agile Modeling". [12]Scott Ambler,"Agile Requirements Management ".

Mahmoud Mostafa Hosny Agile Requirements: A Customer Transparent Process