Get certified - Transform your world of work today

Close

Requirements Engineering

The classic way versus the Agile way

7 August 2017


What do you think about the differences between the classic way of requirements engineering versus requirements engineering done in the Agile way of accomplishing the program or project?
 
Requirements Engineering Classic method Agile method
Order of Activities During the first (closed) phase:
  • Requirements engineering happens as a first closed phase in a project.
  • At the end of the phase, the requirements are complete and in full detail.
  • Later changes (change requests) are treated as exceptions.
Done iteratively and in parallel to design, implementation, and testing:
  • Activities go alongside the complete software life cycle.
  • Stakeholders give their feedback about product increments delivered early.
  • Requirements will be changed and refined following that feedback.
Roles in the Organization Activities are performed by predefined roles:
  • The requirements engineer role is often separate  from other roles.
  • Team members often occupy just one role:
    • Product manager
    • Business analyst
    • Software engineer
    • Tester
  • Each belongs to his or her respective organizational unit.
Activities are performed by interdisciplinary teams:
  • Each team member will have multiple roles:
    • Requirements engineer
    • Software engineer
    • Tester
  • Each team member has to develop the necessary skills
 
Stakeholder Involvement Stakeholders are involved in specific phases:
  • Requirements engineering
  • Proof of concept A-Sample  (e.g., prototype)
  • Test of B-Sample (functions are operational, components are not completely approved)
  • Field test with C-Sample (All components of a serial production)
  • Pre-production with D-Sample (preproduction sample)
Collaboration with stakeholders and customers is continuous:
  • Identify the functional requirements on a business case level
  • Improve and, as needed, split the requirements so that they are "Ready" according to the definition
  • Discover and consider nonfunctional requirements
  • Confirm that requirements are fulfilled
 
Requirements Elicitation Experts predict what the customer wants:
  • Marketing experts:
    • Analyze the market
    • Create customer segments
    • Define and advertise the product-features
  • Up until the product is delivered, customer segments and needs can change.
Customer feedback determines the evolution of the product:
  • Fast delivery of a minimalistic, useful product
  • Gather real feedback from real customers
  • Define customer segments  with more detail (personas)
  • Understand the needs of the customer segments
  • Develop an intuition for innovations that will meet the customer segment needs
  • Deliver product improvements quickly and get feedback
Requirements Documentation Complete and detailed, as early as possible:
  • There are many assumptions that will only be validated much later
  • The long project duration makes changes within the environments more probable
  • Documentation will be outdated and produce a lot of maintenance effort
 
"Just enough" and "Just in time":
  • Documents only cover what will produce lasting value for the stakeholders or the team
  • Documentation goes only up to the necessary depth of detail
  • Documents remain current, accurate, and useful for longer
    • Example: Test cases enhance and detail the requirement documentation
 
Feedback and Rework on Requirements Tedious and long-lasting rework:
  • "First shot has to hit the goal"
  • More effort and more defects in the process of adapting of the requirements to stakeholder feedback, new findings, contextual changes, and risk
Fast follow-up of small, incremental changes and developments to the product:
  • Knowledge gained in one sprint will be considered in the next one
  • Continuous, direct feedback will allow a fast adjustment of the requirements
 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4.5 (6 ratings)

Comments

Be the first to add a comment...


You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe