Campbellodeon

This was the second session I attended on Wednesday. This was the first of the three “break-out sessions” that were held in the afternoon. These sessions lasted 70 minutes. I chose this session over the following two available sessions: “Aspect Oriented Programming: Myths and Realities” by Ramnivas Laddad and “B2B Web Services Integration Layer” by Sony Mathews. I regretted choosing this session after it was over and even moreso on Friday when I attended a separate break-out session about programming with Aspects. The lesson learned here is that I should have spent more time researching the presenters and took less stock in the title of the presentation. As you can see by clicking the link to Ramnivas Laddad’s website, he is a thought leader in Aspect Oriented Programming and I missed an opportunity to hear one of his presentations. What are you going to do? After looking at some other write-ups of the conference sessions, I think I will follow their lead and include the session information provided by TechTarget.

Agile Requirements from Static Specifications
Presenter: Vincent Frisina

The unfortunate reality of large-scale development is that requirements evolve in unexpected ways as the needs and understanding of the various stakeholders in the project change. This is often complicated by a slow-moving requirements analysis and specification process that isolates developers from stakeholder feedback. The development team is then caught in the middle trying to catch up with a changing system while trying not to fall behind in their deliverables. In this case study, we examine a number of techniques that have allowed one team to stay on top of shifting requirements and limit rework costs.

For this session, the slides were handed out. At the moment, those slides are not available anywhere that I am aware of. Unfortunately, until those slides are available these notes may not make a whole lot of sense. This post will be updated when those slides are available somewhere online. Feel free to comment if you have questions.

Beginning of notes

• This session applies to very large, long term projects: projects where Word is not sufficient for tracking requirements
• Developers have a love/hate relationship with requirements
• Document Centric Requirements Management
  • output of requirements analysis is a document (usually written in Word, maybe an Excel spreadsheet)
  • communication is achieved by passing documents around
  • problems arise with regard to vocabulary and contradictions between reviewers
• Example Project
  • ~10,000 pages of specifications, 100’s of documents
  • constant revisions of requirements
  • ~10 stakeholder organizations providing requirements
• Agile Development
  • understanding that there is going to be change and being prepared to deal with it
  • can be difficult to adjust to
  • not waterfall
  • utilizes “Parallel Requirements Feedback Cycles”
    • Users and Stakeholders work with Business Analysts to improve user understanding of the system
    • Developers work with Business Analysts to improve analysis
• Predicate Catalog -> Domain Dictionary
  • create a dictionary of common concepts
  • where code uses a predicate, the requirements should cite the domain dictionary
  • expect gradual acceptance from analysts
• Query Objects -> Logical Data Model
  • Entities and related queries define a logical model
    • functional requirements sit on top of explicit or implicit models -> make them consistent
    • existing logical models may be too low level
• Validation Rules -> Data Consistency Requirements
  • extract cross-cutting consistency and validation rules from functional requirements
• Development Team Considerations
  • be prepared fro additional ramp-up time
  • developers must review and questions the requirements
  • seek out overlaps and conflicts between teams
  • team leader must insure that feedback occurs
  • consider official “librarian” roles on the team
    • this role needs to understand the business domain

A few closing points:

• Overall, I was disappointed in this session. The presentation seemed more like a case study than anything else. The presentation did not into enough detail about the specific project or about the methods employed to be particularly useful.
• I agree that mammoth projects require a different method for requirements management, but I just don’t believe that there are many gigantic projects (like the one this presentation was geared toward) currently going on. I am probably mistaken, but I know that the methods here did not apply to the kind of work that I do or have done at any time in my career.
• Lastly, I got the impression that the presenter did not want the attendees to ask questions. He did encourage people to ask questions, but when the questions came his comfort level changed dramatically. The lesson learned here is that you need prepare for questions just like you practice your presentations. As a presenter, you need to go through your presentation and think about what questions you might be asked and be prepared to answer them. I think it is also beneficial to give your presentation to a couple of small groups of colleagues to solicit feedback on your style but also to get a baseline of questions that you should be prepared to answer.

Next up: Java Specialists in Action by Heinz Kubutz