Your SlideShare is downloading. ×
Agile requirements engineering
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Agile requirements engineering

106

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
106
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. 1
  • 2. 2
  • 3. Study: 68 percent of IT projects fail! Source: www.techrepublic.com 3 www.danradoiu.ro
  • 4. Facts and Figures  17% of large IT projects go so badly that they can threaten the very existence of the company.  On average, large IT projects run 45% over budget, while delivering 56% less value than predicted.  A truly stunning 78% of respondents reported that the “Business is usually - or always! - out of sync with project requirements”. Source: Why Projects Fail 4 www.danradoiu.ro
  • 5. Agile Requirements Engineering A practical approach
  • 6. Yours truly :) 6 www.danradoiu.ro
  • 7. Agenda  Seven Questions Analysis.  The Now, The Work and The Goal.  Navigational Mockups.  F.U.R.P.S. Requirements.  User Stories and Usage Scenarios. 7 www.danradoiu.ro
  • 8. What do we search to achieve when performing requirements engineering? 8 www.danradoiu.ro
  • 9. To describe that product or service (a great one, if it’s possible) that will put a smile on our customer’s face. 9 www.danradoiu.ro
  • 10. Each question reveals a different dimension How? Why? Functional Motivational Temporal Where? Who? Organizational What? Conceptual 10 When? Geographical The Product How Much? Quantitative www.danradoiu.ro
  • 11. In every job that must be done, there is an element of fun. You find the fun, and - SNAP - the job's a game! - Mary Poppins, A Spoonful Of Sugar 11 www.danradoiu.ro
  • 12. What? A little customization…  How did you get the idea?  Conceptual How will a success story (the perfect one, if it’s possible), will unfold in your case? 12 www.danradoiu.ro
  • 13. Who? People and Organizations A little customization…  Who are they? Those entities that will: Investors Customers IT Ops Invest their money Use the product The City Hall, Governmental Institutions etc. Keep the system running Try to make you fail Competition Give you different permits and approvals 13 Commercial Partners Invoice you or being invoiced by you www.danradoiu.ro
  • 14. Who? People and Organizations A little customization…  What do they need?   Why? Motivational Things that can be acted upon (real-life objects, services, functionalities). For what purpose?  14 Motivations attached to these real-life objects, services, functionalities. www.danradoiu.ro
  • 15. Why? Dig beyond the surface  Motivational Don’t take the first given reason. Look for something meaningful for the business. The marketing manager needs a sales report.  Why?   To what end?   To see the sales figures. To check if the company products are in demand. And then?  15 If necessary, to initiate corrective measures (as marketing campaigns). www.danradoiu.ro
  • 16. All of them in one place  After collecting their needs and whys, we need to see if the envisioned functionalities satisfy them. 16 www.danradoiu.ro
  • 17. How? A little customization…  Functional How will the envisioned product fulfill their needs?  A clickable Happy-Path.  Navigational and UI Mockups. View Message Main Page Login Inbox Compose Delete message 17 Viewing Message Editing Message Deleting Message Warning www.danradoiu.ro
  • 18. When? A little customization…  Temporal Take a look to a real calendar to identify those special days or periods in the product lifecycle.  18 And then, go deeper: When is the most busy hour of the day, day of the week, period of the month for a product of this kind? www.danradoiu.ro
  • 19. Where? A little customization…  Geographical What are those physical places that your product will impact (or be impacted by)?  Accessed, administered, attacked from? Hosted where? Backups stored in? Delivered at?  What about in five years from now? 19 www.danradoiu.ro
  • 20. How Much? A little customization…  Quantitative Now, let’s go back and challenge, from a quantitative point of view, every answer we have received so far.  Only one portal? What it should happen in order to have two portals?  One portal administrator? What if he gets stranded on a tropical island, without any internet connection?  How many visitors (at minimum) per month to keep de business running? 20 www.danradoiu.ro
  • 21. The Now, the Work and the Goal The "Now" The Work The Goal Who is going to work in this project? Who offers the same services now? 21 Who is going to use the product? www.danradoiu.ro
  • 22. Let's try a clickable mockup  Microsoft Word, the simplest tool to build a navigational mockup. 22 www.danradoiu.ro
  • 23. Don’t forget, gathering requirements for a product means more than identifying its functionalities! 23 www.danradoiu.ro
  • 24. F.U.R.P.S.  An acronym representing a model for classifying software quality attributes (functional and non-functional requirements):  Functionality - Feature set, Capabilities, Generality, Security.  Usability - Human factors, Aesthetics, Consistency, Documentation.  Reliability - Frequency/severity of failure, Recoverability, Predictability, Accuracy, Mean time to failure.  Performance - Speed, Efficiency, Resource consumption, Throughput, Response time.  Scalability - Testability, Extensibility, Adaptability, Maintainability, Compatibility, Configurability, Serviceability, Installability, Localizability, Portability. 24 www.danradoiu.ro
  • 25. User Stories and Usage Scenarios  User Story:  A user story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it. As a <role>, I want to <functionality>, so that I can <benefit>.  Usage Scenario:  It details a User Story, providing the necessary details for certain situations that require so. Given <situation>, when <event or trigger>, then <action>. 25 www.danradoiu.ro
  • 26. A piece of reality  As a visitor I want to login so that I can access my Inbox  Given the user is authenticated,   Given the visitor is not an authenticated user,    When the visitor dials www.gulliver-e.com, Then this page is displayed. When the visitor tries to access a member-only page, Then he gets redirected to the Main Page. Given the visitor entered three times in a row wrong credentials,  26 When dials www.gulliver-e.com, Then he gets redirected to the Inbox Page. When he tries for the fourth time, Then a Captcha is added to the page (to avoid bots). www.danradoiu.ro
  • 27. And now, some questions for your answers  … or is the other way around? :) 27 www.danradoiu.ro

×