Development Lifecycle: From Requirement to Release


Published on

This presentation was given as part of the User Experience (UX) community update series of meetings in the University of Virginia Library. For more information:

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Development Lifecycle: From Requirement to Release

  1. 1. DEVELOPMENT Lifecycle From Requirement to Release<br />UX Update Meeting<br />20 April 2011<br />Julie Meloni<br />Lead Technologist/Architect<br />Online Library Environment, UVa Library<br /> // @jcmeloni<br />
  2. 2. Functional requirements define the functionality of the system, in terms of inputs, behaviors, outputs.<br />What is the system supposed to accomplish?<br />Functional requirements come from stakeholders (users), not (necessarily) developers.<br />stakeholder request -> feature -> use case -> business rule<br />Developers can/should/will help stakeholders work through functional requirements.<br />Functional requirements should be written in a non-technical way.<br />Functional Requirements<br />
  3. 3. Example functionality: representation and manipulation of hierarchy<br />Description: The GUI should allow users to view and interact with hierarchical structures representing the intellectual arrangement and the original arrangement of files and directories within ingested accessions. For each component level in the intellectual arrangement, the user interface should present associated digital assets and an interface to view and edit descriptive metadata elements. <br />Specific Components: collapse and expand record nodes for viewing (applies to both the original ingest and the intellectual arrangement), add new child record, add new sibling record, copy all or part of the existing structure to the intellectual arrangement, delete a record in intellectual arrangement.<br />Example Functional Requirement<br />
  4. 4. An epic is a long story that can be broken into smaller stories.<br />It is a narrative; it describes interactions between people and a system<br />WHO the actors are<br />WHAT the actors are trying to accomplish<br />The OUTPUT at the end<br />Narrative should:<br />Be chronological <br />Be complete (the who, what, AND the why)<br />NOT reference specific software or other tools<br />NOT describe a user interface<br />Writing USE CASES (or epics)<br />
  5. 5. Stories are the pieces of an epic that begin to get to the heart of the matter.<br />Still written in non-technical language, but move toward a technical structure.<br />Given/When/Then scenarios<br />GIVEN the system is in a known state WHEN an action is performed THEN these outcomes should exist<br />EXAMPLE:<br />GIVEN one thing <br />AND an other thing <br />AND yet an other thing <br />WHEN I open my eyes <br />THEN I see something <br />But I don't see something else<br />Writing stories<br />
  6. 6. Scenario: User attempting to add an object<br />GIVEN I am logged in <br />AND I have selected the “add” form<br />AND I am attempting to upload a file<br />WHEN I invoke the file upload button<br />THEN validate file type on client side <br />AND return alert message if not valid<br />AND continue if is valid<br />THEN validate file type on server side<br />AND return alert message if not valid<br />AND finish process if is valid<br />Actual example<br />
  7. 7. Developers involved at the story level<br />Writing stories<br />Validating stories<br />Throwing rocks at stories<br />Getting at the real nitty-gritty of the task request<br />Moving from story to actual code<br />Stories written in step definitions become Ruby code<br />Tests are part of this code<br />Code is tested from the time it is written<br />Writing code<br />
  8. 8. So, the butterfly effect…<br />When one change in a complex system has large effects elsewhere, through a sensitive dependence on initial conditions.<br />Epics and stories do not have to be golden, but changes should be carefully considered<br />Developers illuminate the potential effects of changes<br />The cycle of epic, story, coding begins again<br />This includes any story that touches the changed story<br />Never stop communicating<br />
  9. 9. We don’t ever think we’re finished when we release a product<br />Each release has with a list of known issues and potential areas of improvement<br />We go through the cycle of epic, story, coding/testing, user testing, story editing, coding/testing, (etc) again and again.<br />Products are organic and grow upward and outward<br />…but if you want to lop off part of that tree, expect there will be systematic changes <br />Developers are there to ensure the tree doesn’t fall on your house.<br />releasing<br />