A Context for Requirements Handling in an Agile Workflow

Caton, Paul

doi:10.5281/zenodo.17968141

A Context for Requirements Handling in an Agile Workflow

Caton, Paul

Publisher: Zenodo
DOI: 10.5281/zenodo.17968141
Repository: zenodo.org
Language: en

Abstract

When King’s Digital Lab (KDL), an RSE unit based in the Faculty of Arts and Humanities at King’s College London, began operations in 2016 we quickly adopted the industry-standard DSDM Agile methodology. Its emphasis on a fixed-time-and-cost basis with flexibility on features aligns well with the grant-funded projects work we commonly do. Our SDLC includes DSDM-recommended steps and documentation which we have found very helpful. However, because we have small solution development (SDT) teams each working on several projects simultaneously, workflows can be complex and it has been challenging to fully and consistently follow Agile precepts, especially with respect to handling project requirements. We like the theory of moving from initial high-level requirement descriptions to greater specificity via iterative development but in practice have found that while a typical Agile try/asses/adjust/try again fosters creativity and refinement in implementation it also brings a constant risk of confusion and inefficiency for the SDT. We have come to see that fast-paced iteration demands a fixed context: something consistent, intuitive, and convenient that allows both SDT and project partners to produce and keep track of evolving requirement descriptions and the constantly moving parts - discussions, decisions, task creation, etc. - that surround them. ‘Context’ here is not quite an approach (as, for instance, Specification by Example), or a formalized set of practices (like the Requirements Development & Management Practice Area of CMMI), or a purpose-built software tool (e,g. Altium 365) but might incorporate aspects from any or all those things. Drawing from our experience at KDL this talk will firstly discuss specific issues in requirements handling which can thwart Agility and frustrate all parties in a project. It will then set out aims, principles and practical considerations pertinent to a fixed context that facilitates rapid iteration in an environment of multiple complex workflows. Acknowledgements Colleagues at King's Digital Lab, King's College London, and in particular Senior Research Software Engineer Geoffroy Noël with whom I have had many helpful conversations on the subject of the talk.A recording of this session is available on YouTube: https://youtu.be/O27tomTwXD0

Full text

A Context for Requirements Handling in an Agile Workflow Paul Caton Senior Research Software Analyst & Deputy Director King’s Digital Lab King’s College London King’s Digital Lab (KDL) •RSE group based in the Faculty of Arts & Humanities (FAH) at King’s College London •13 full-time staff playing various roles, most of them development focused •principal remit is to serve the FAH research effort •main activity is working with FAH scholars on grant-funded research projects •we also work on projects with a variety of external partners KDL project work context A Solution Development Team (SDT) works on a project SDT usually has three members: •research software analyst •research software UI/UX designer •research software developer Each person in the SDT is usually working on several other projects at the same time Any SDT member on one project might be reassigned to another project if circumstances make it necessary Work is nominally scheduled to a calendar of fortnightly timeboxes, the ideal being to try to focus on one project during a timebox But multiple concurrent projects, all at different stages, make scheduling irregular and often force plans to change In all this, we still try to be Agile Few partners come to us with funding already secured. Most come with an idea for a proposal. If the proposal is a good fit for us, then we work with them to develop it. For the funding application we provide them with a Product Quote KDL Product Quote A formal document describing what KDL would do in the project if it were funded. The work to be done is described in prose in general terms and itemized in a table of high-level requirements Using high-level descriptions of requirements in our Product Quotes is appropriate because: §Fits the typical constraints of proposal formats §Best not to commit to specific details given the lengthy time there might be between application submission and the start of project work §Adheres to the Agile philosophy of allowing for discovery and refinement of requirements through open and iterative prototyping Project work involves starting from something like this: . . . And ending with something like this: One tricky issue: granularity High level descriptions compress & elide the fact of several distinct aspects. One record to serve them all, or multiple records? If only one, how are aspects distinguished? If multiple, how are the records organized? How is content distributed among them? OR OR Thank you!