Development Lifecycle: From Requirement to Release

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

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

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

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)

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

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

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

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

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

http://www.academicsandbox.com	533
http://www.thickbook.com	405
http://dev.thickbook.com	8
url_unknown	6
http://academicsandbox.com	6
http://translate.googleusercontent.com	1

Development Lifecycle: From Requirement to Release

by Julie Meloni on Apr 20, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

6 Embeds 959

Statistics

Development Lifecycle: From Requirement to Release — Presentation Transcript