Seilevel
Seilevel Home
Back to Blog Home - Requirements Defined

Thursday, September 13, 2007

Back to School

The first day of school brings back great memories for me. Going shopping for a Superman backpack, trying out the new lunchbox (how will the thermos, two desserts and a note from mom all fit in there?), and getting ready to see old friends and make new ones. It's a time of excitement and of nervousness. Will I like my teacher? Will I have a lot of homework? How will I ever read all those books on the bookshelf?!? But it's also a time of opportunity.

Starting on a new requirements project can be a lot like going back to school. You get to meet new people, discover new areas and challenges in your organization, and maybe even get a new lunchbox! But perhaps most importantly, you get the chance to learn new things about gathering requirements.

Wait ... "learn new things about gathering requirements?" You already know how to gather requirements, right? Shouldn't that sentence read "show off your skills with requirements gathering" or "teach others about requirements?" Well, it certainly could be either or both of those. Hopefully you're able to educate the rest of the team about good requirements engineering practices during every project, and hopefully the team will be impressed with your RE prowess. However, I think the opportunity for each of us to learn more about what we do, while we do it, is even more important.

If you've been working in RE for a while, you may have a typical pattern or approach to your work, and that approach probably works well. That said, each of us can always learn something to help improve our work. Maybe a particular model did or didn't work especially well on this project. What made this project different? What can you take away from this experience to improve both the current project and your approach for the next one?

In addition to this "on the job learning," new projects provide great opportunities to find new sources of information outside the project. What new blogs, journals, discussion groups, or books are available on RE? What local professional associations meet to discuss software development topics?

The start of a new project only provides a good opportunity to learn
it's up to you to take advantage of that opportunity. Use the excitement and energy a new project brings to help you discover new things about RE. Those discoveries will improve both your skill set and the project you're working on, and that new Superman backpack will certainly get the conversations flowing!

Requirements Defined Newsletter Bookmark and Share

2 Comments:

Anonymous Anonymous said...

Projects are meta to the work at hand. Project-based requirements specification leads to a loss of traceability when the requirements are focused on the project rather than the product and its lifecycle, which will involve many projects.

Whatever the project produces, the produced thing persists, as does its requirements. They persist together, side-by-side for a very long time--maybe forever.

Forever makes them operations, rather than projects. Project managers do not make good operations managers. What gets lost is where the line is between projects and operations. Both have requirements.

The processes used in an operation have requirements. Projects have requirements. Operations and projects move at different speeds and intersect in implementation. Operations constrains projects.

The messiness of the project-operations divide impacts requirements.

9/13/2007 10:58 AM  
Blogger Anthony C. said...

This post is being discussed here

http://www.seilevel.com/messageboard/showthread.php?t=672

9/13/2007 11:44 AM  

Post a Comment

<< Home