Tom Ramcigam (magicmarmot) wrote,
Tom Ramcigam
magicmarmot

Day from hell #2

So the day started off reasonably well. I went to the HR person and mentioned that I had a problem with the dress code, in that I have no clothes that will allow my to have tucked-in shirts. She said that it would be no problem, that I looked fine-- I'm pretty sure that she was happy that I brought it up rather than saying nothing, so points for me.

It went downhill from there.

My current task is to go through the software requirements document (SRD)piece by piece and log things that need to be corrected, or things that need to be explained. Bear in mind that an SRD is a formal piece of engineering documentation that is key to things like design and test. This one is 147 pages long.
I started yesterday. Today I made it through page 87. So far I'm up to 183 errors: about 10-15% of them are spelling and grammar errors which are expected and easily fixed.
However, about another 10-15% are requirements which are missing. Like here is a specific requirements ID, and there is nothing there, it's just blank.
And then there are the non-requirements. Things like this:

During design, engineers shall review with marketing the different options and trade-offs.


Okay, first: that is not a software requirement. And by the time it gets that far into the design phase, this kind of stuff had damn well better be locked down, or the project will never end.

Another good one:

update rate of the display shall be fast enough that the user does not find it objectionable.


And what framerate would that be exactly?

My personal favorite is the requirement that hides multiple requirements. Something like:

Requirement #1996:
The ball shall be in a box. The box will be blue, and large enough to contain the ball without rolling. The box shall be made of plastic, and withstand a force of 120PSI normal to the surface without buckling.


Before you think that I'm being a stickler, remember that the requirements document is the basis of both the design and the test documents. If you have a clear requirements doc, you can then design to those requirements and test to make sure that those requirements are fulfilled. It is critical to have clean requirements. These aren't even close.

And I have to have a list of questions formed by tomorrow.

I am beginning to understand why they were willing to pay so much.
Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 1 comment