ITKE Community Blog

Jan 7 2013   9:10PM GMT

Book giveaway: Mastering the Requirements Process

Michael Tidmarsh Michael Tidmarsh Profile: Michael Tidmarsh

Software image via Shutterstock

Do you have trouble finding those software issues? With many errors coming from within requirements, Suzanne Robertson and James Robertson’s book, Mastering the Requirements Process: Getting Requirements Right, teaches you how to gather and verify requirements properly so your software works efficiently. We’ve got an excerpt of the book up on our IT Bookworm blog.

To win a copy of the book, tell us your company’s process for finding complete requirements for a project. Good luck!

5  Comments on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Jaideep Khanduja
    Requirement for any project is never complete in one go or in one phase. In current scenarios it is dynamic and keeps changes even during the project due to many internal and external factors. Best way that we adopt is to keep customer/ end user/ process owner aligned with each stage of our project throughout and get it vetted by them.
    9,040 pointsBadges:
    report
  • Harisheldon
    If you are the IT Project Manager for the project, you will need to assembly your team that is savy in not only the software that is being created, but also the hardware that the systems are working on.  Here, in the DOD, we work with a lot of programs from different vendors that have worked for years.  Now, with the new policy of ensuring that all systems are not only up-to-date to the most current OS, these vendors need to re-write the code for the said OS.  This is like pulling teeth and the vendor then demands a new EULA.  One example that I can personally comment about is macro that was written for the Air Force for ammunition.  The program worked great for OS Vista and Office 2007, but, when we upgraded to Windows 7 and Office 2010, it would no longer work.We tried to recreate the problem by building a box with the old OS and Office, of course, it worked fine, but when the new Office was installed, that is where the problem arose.  Needless to say, it took four months of trial and error and a lot of documentation to present to the vendors that their program no longer worked and it need to be fixed for the new standards.It took awhile for the vendor to finally find the problem and send out the repair, but, they felt that we should have stayed with the old Office because that is when the program was written.Vendors need to realize that of course, the DOD, and also corporations, will upgrade to newer and sometimes better software and if the program that is written to work with these base-line programs, they should already be working on the problem before it arises and complaints start coming in.Luckily, when we did the testing, I wrote every line and error code that appeared on the screen and also included each and every command that we tried.  By doing this, the vendor saw what we had attempted and the results of that test.  The final report came to about 70+ pages, but, you could say that we covered all the bases for the vendor to look at and they could not say that we did not try.So, when testing and trying to repair something, document everything.  Every line, command and error message.  This way, it can be retested with the notes you created and see the same results and just check it off the list.
    5,530 pointsBadges:
    report
  • carlosdl
    Requirements gathering is probably one of the most difficult and delicate phases of a software development project. Part of the problem is that users frequently fail to explain their real need or problem, and instead they request what they think is the solution. To avoid this problem, we ask as much questions as necessary, to make sure we fully understand the real needs or problems of our users.  Typically, we ask many "why"s (why are  you asking for this? why is this a problem? etc) and many "what if"s (what happens if we do this instead? what if we change this process? etc). Then, when we think we have completely understood our users' needs, we write a requirements document that they have to read and accept.  Our requirements document usually includes a lot of "must"s, and almost never includes the word "should".  Words are very important, because they can remove or add ambiguity.  
    68,585 pointsBadges:
    report
  • Michael Tidmarsh
    Congratulations Carlos, you have won the book! Watch out for an email from me so I can sent it to you.
    28,795 pointsBadges:
    report
  • carlosdl
    Great, thanks.
    68,585 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: