The document discusses the software development lifecycle from requirements to release. It covers defining functional requirements, writing epics and use cases, developing stories, writing code, testing, and releasing software. Stories are broken into given/when/then scenarios and written before code. Developers are involved at each stage to help validate requirements and illuminate the effects of any changes on the system. The development process is iterative, with continuous communication and revisiting of stories and code after each release.

1. DEVELOPMENT Lifecycle From Requirement to Release UX Update Meeting 20 April 2011 Julie Meloni Lead Technologist/Architect Online Library Environment, UVa Library jcmeloni@virginia.edu // @jcmeloni

2. Functional requirements define the functionality of the system, in terms of inputs, behaviors, outputs. What is the system supposed to accomplish? Functional requirements come from stakeholders (users), not (necessarily) developers. stakeholder request -> feature -> use case -> business rule Developers can/should/will help stakeholders work through functional requirements. Functional requirements should be written in a non-technical way. Functional Requirements

3. Example functionality: representation and manipulation of hierarchy 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. 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. Example Functional Requirement

4. An epic is a long story that can be broken into smaller stories. It is a narrative; it describes interactions between people and a system WHO the actors are WHAT the actors are trying to accomplish The OUTPUT at the end Narrative should: Be chronological Be complete (the who, what, AND the why) NOT reference specific software or other tools NOT describe a user interface Writing USE CASES (or epics)

5. Stories are the pieces of an epic that begin to get to the heart of the matter. Still written in non-technical language, but move toward a technical structure. Given/When/Then scenarios GIVEN the system is in a known state WHEN an action is performed THEN these outcomes should exist EXAMPLE: GIVEN one thing AND an other thing AND yet an other thing WHEN I open my eyes THEN I see something But I don't see something else Writing stories

6. Scenario: User attempting to add an object GIVEN I am logged in AND I have selected the “add” form AND I am attempting to upload a file WHEN I invoke the file upload button THEN validate file type on client side AND return alert message if not valid AND continue if is valid THEN validate file type on server side AND return alert message if not valid AND finish process if is valid Actual example

7. Developers involved at the story level Writing stories Validating stories Throwing rocks at stories Getting at the real nitty-gritty of the task request Moving from story to actual code Stories written in step definitions become Ruby code Tests are part of this code Code is tested from the time it is written Writing code

8. So, the butterfly effect… When one change in a complex system has large effects elsewhere, through a sensitive dependence on initial conditions. Epics and stories do not have to be golden, but changes should be carefully considered Developers illuminate the potential effects of changes The cycle of epic, story, coding begins again This includes any story that touches the changed story Never stop communicating

9. We don’t ever think we’re finished when we release a product Each release has with a list of known issues and potential areas of improvement We go through the cycle of epic, story, coding/testing, user testing, story editing, coding/testing, (etc) again and again. Products are organic and grow upward and outward …but if you want to lop off part of that tree, expect there will be systematic changes Developers are there to ensure the tree doesn’t fall on your house. releasing