Distributing Responsibilities to Engineer Better Requirements: - PowerPoint PPT Presentation

Distributing Responsibilities to Engineer Better Requirements: Leveraging Knowledge and Perspectives for Students to Learn a Key Skill Olly Gotel , Vidya Kulkarni, Moniphal Say, Christelle Scharff, Thanwadee Sunetnanta olly@gotel.net REET 2009

Overview • The general challenge • Our global project • The specific challenge • Initiatives to improve the quality of requirements • Quality assessment • Outcomes • Lessons

The general challenge • Learning to write / value quality requirements • The typical quality of requirements on student projects • The constraints of many degree programs: • Issues at undergraduate level • Issues at postgraduate / specialist level • Issues exacerbated in global settings • How to complement and leverage skills?

Our global project • 5 universities, 4 countries, 8 classes, 7 sites • 3 prior years of collaboration • MultiLIB -- what happened in 2007 • Need to deploy - problem of time pressure, requisite skills, evolving requirements, quality

The specific challenge • How to give students a realistic software development project experience, while learning the requisite skills to write requirements, without compromising quality • How to create an experience that enables students to see the value of spending time on requirements

Technology Socialization Competition Software Engineering 4th Year - 2008 Globalization 12 hours US Pace University 2.5 hours NYC Campus 9.5 hours CAMBODIA INDIA Royal University US University of Phnom Penh Pace University of Delhi Pleasantville Campus US Students and IT Professionals (Global Bank in NYC) THAILAND CAMBODIA Mahidol Institute of University Technology of Cambodia

Initiatives to improve the quality of requirements • Coaching of client proxies and developers: • Requirements training and champions of the client / developer communication • N-version development competition: • Expose the requirements to multiple perspectives • Requirements-based selection • Auditing of all processes and products

The educational model • MultiLIB software was for the Cambodian school • Client / end-user represented by client proxies (5 Cambodian undergrads) • Each client proxy assigned a coach (5 US grads)

Client-side set-up

The educational model (cont.) • Each client proxy sponsored a development team (5 teams - Indian, Cambodian, Thai, NYC, NY PLV) • Each development team assigned its own coach (5 US grads) • Each development team assigned its own set of auditors (5 * 3 IT professionals)

A requirements-focused triad

The model -- 5 requirements-focused triads

Client-side requirements activities • Requirements producers and custodians • Cambodians -- no background, so RE-O-Poly • Coach team re-engineered draft RSD and helped to set up a RM system; client proxy team worked with the client -- buy-in and transfer of ownership / apprenticing • Focused on writing testable requirements for RFP and selection • Handled multi-way feedback and versioning

Developer-side requirements activities • Requirements consumers • Teams - little background, so coached • Coaches encouraged and facilitated communications with the client-side • Set up a process to enable and demonstrate requirements satisfaction (traceability key) • Audit preparation, response and iteration

Audit-side requirements activities • Requirements champions -- external eyes • Publication of audit checklists - for process and all products • To improve quality of the requirements -- 5-way audit of RSD, at two key points • To improve quality in terms of final products meeting requirements - 5 ongoing audits per development team • SQA manager and traffic light dashboard

Fragments from RSD audit checklists

What the RSD was exposed to 71 functional and 4 non-functional requirements

Quality assessment • Satisfaction of requirements (high, medium, low priority and weighted) • Development teams and their coaches score themselves • Audit team and SQA manager - rank all processes and products • Cambodian clients and their coaches rank all products (and account for the above in their final assessments)

Outcome from requirements coaching • These pairings worked! • Cambodian client proxies REALLY engaged in the requirements process -- it empowered their negotiations and decisions • All developers became pro-active • Coaches took their requirements knowledge to the next level • Requirements actually evolved and improved, all sides managed this and saw the value

Clients really worked with and trusted their coaches

Outcome from audit cycles • Requirements audits: • 5-way audits reinforced any concerns -- students took notice and acted • Learned to prioritize and deal with conflicts • Audit of other SDLC artifacts: • Visible dashboard motivated teams! • Both processes and products improved • Auditors put their knowledge into use

Requirements maturity profiles

Outcome from having 5 triads • Multiple triggers for requirements change -- from VERY diverse perspectives -- caught DIFFERENT things (esp. assumptions) • Competition fueled requirements clarification and improvement (FAQ materialized) • Closer the coupling, the more extensive the communication, the better the end quality • Well written, prioritized and ranked functional requirements -- all agreed it was a fair competition and final selection process

Outcome -- something that DID NOT improve • Non-functional requirements: • Poorly written / untestable • The selection decider -- sleepless nights and a BIG lesson for all! • Post-analysis: • 0.05% of requirements in RSD were NFRs • NFR matters dominated informal communications about the requirements

Revisiting the specific challenge • How to give students a realistic software development project experience, while learning the requisite skills to write requirements, without compromising quality • How to create an experience that enables students to see the value of spending time on requirements

Lessons • Educational cost/benefit: • MultiLIB is now deployed in Cambodia :-) • BUT, the overhead was phenomenal :-( • Potential industry value in: • Requirements coaches -- apprentice models work for BOTH producers and consumers • Multi-perspective auditing is phenomenal • Early alerting systems -- checking whether informal discussion topics align with formal

For more information... http://atlantis.seidenberg.pace.edu/wiki/gsd2008

Special thanks to our entire 2008 global software development team

More thanks • Supported by a National Collegiate Inventors and Innovators Alliance grant (#3465-06) -- “Incubating the Next Generation of Global Software Development Entrepreneurs” -- (2006-2008) and a Campus Second Life scholarship • We thank all the 159 students who have been involved to date and ITC faculty/school

Distributing Responsibilities to Engineer Better Requirements: Leveraging Knowledge and Perspectives for Students to Learn a Key Skill Olly Gotel , Vidya Kulkarni, Moniphal Say, Christelle Scharff, Thanwadee Sunetnanta olly@gotel.net REET 2009