Requirements Elicitation - Lessons Learned

Summary

This page is the result of various observations made about the process the VCDE and NCI teams used during a short phase to gather and organize requirements for the new semantic infrastructure.

Notes and Observations

Tools:

• Store all the information in a Semantic MediaWiki to save time, facilitate use, improve traceability
• Centra is not as reliable as it should be.
• Having all artifacts in one wiki vs. confluelnce wiki and VKC wiki could have made flow easier.
• Possibly a quick wiki markup language training in the beginning would have helped some analysts move through the templates with more ease.

Process

• Weekly meetings were great for asking questions and planning next steps
• A brief training on SAIF/ECCF and key concepts of them seems to be useful for all team members
• It would be helpful to have a second person on the interview call to help take notes
• In some cases one analyst wrote the requirement statement and another wrote the use case. It would have been a smoother work flow without these transitions from one person to another.
• "I think the most important aspect of the project that I thought was missing, at least in my perception, was the big picture." - remedied by big picture development.
• A clearer indication of the final goals and deliverables from the start
• Requirements elicitation process was established and refined
• There is value in establishing a requirements/use case analysis roadmap, as a communication tool to highlight key stages in the process, roles involved and artifacts produced, as well as showing the influence of the new SAIF/ECCF directions. This was also confirmed by the existing analysts on the team.
• The different use case levels bring in certain subjectiveness, e.g. whether some use cases are at Kite, Sea or even Underwater level; this needs to be kept in mind when documenting the use cases in the EA repository; to address this the following heuristics can be applied
  • first consider the granularity of steps mentioned in the use case description
  • if steps are of low granularity, the use case can be of a Sea or Underwater level, identifying one or more possible technical services to support the functionality in the steps
  • in the case of a Sea vs Underwater dilemma, apply the reusability principle, i.e. if reusable, it is an Underwater candidate
• There appear to be some issues with how the EA tool handles UML use case stereotypes developed for the purpose of supporting different levels. This may need to be revisited in future;
• It would have been useful if an ontology-style facility was available to search for use cases, actors or use case goals; the benefit would be even higher in larger scale projects, which would need to support a larger number of stakeholders and analysts/architects;
• There was not sufficient time to fully explore the value of the ODP community concept from the point of view of ECCF traceability. There is recognition however by the team members of the value of the community concept in supporting the development of a community-based ontology as well as its importance in encouraging thinking about the importance of policy design;
• The current approach was mostly broad but shallow coverage, and only in one example (i.e. 21090 datatype support) was there an attempt to provide a deep coverage; if there is more time for this project, there should be more effort committed in this direction to facilitate handover to software developers.
• More formal business analysis approach -  I strongly feel that we should have tackled this project with a more formal business analysis approach.  What I mean by this is that I think that we should have started from the beginning modeling the use cases using a hierarchical structure and then delved into them more.  The enterprise stakeholders (represented by Denise) could have outlined the cloud use cases.  We then should have mapped the forum postings into these.  Anything that didn't fit would have generated more/new use cases. Anything that we didn't fully understand would have led to requirements elicitation interviews. The next step would have been to create a requirements document.
• Clearer indication of level of effort
• More specific tasking with deadlines
• Requirement and use case templates were refined
• Bea as project manager - she did an excellent job keeping the project on task and following up on action items
• Denise as lead advisor - her focus and vision were great assets for the team
• Flexibility shown by team members realizing we were learning as we were going along

Recommendations for Next Steps

• It may be useful to continue this team's involvement during the development phase of whatever project(s) will be implementing them. I feel that there is significant expertise that has been built up in the team that may not exist on paper in the various artifacts we produced.
• As next step, I would spend sometime between now and next round of req. gathering on formalizing/describing the full process covering requirements statements, interviews, use case development, categorization etc. leveraging Zoran's diagram and using existing (or improved versions) of wiki/UML templates.- Going forward, it would be good to have multiple subteams/groups; subteam for process development, subteam for actual analysis- A brief training on SAIF/ECCF and key concepts surronding them seems to be useful for all team members
• Going forward, it would be good to have multiple subteams/groups; subteam for process development, subteam for actual analysis