UX Update Meeting20 Apri l 2011

DEVELOPMENT LIFECYCLE From Requirement to

Release

Julie MeloniLead Technologist/Architect

Online Library Environment, UVa Libraryjcmeloni@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 fi les 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.

Specifi c 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 fi le

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 eff ect… 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 fi nished 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