Jim Schardt’s Blog

Thinking of your system / software / business unit as a black box is a great way of avoiding statements that are not requirements. Consider the statement, “R-1.1 The Payroll Department shall send the Summary Employee Report to the Accounts Auditor each Friday by 1600 GMT.” This requirement is for the “Payroll Department” system. The black box represents the entire Department. As a requirement for the Department the R-1.1 statement describes something (the Summary Employee Report) that goes from the inside of the black box to the outside, namely to the Accounts Auditor. We can experience and measure the report leaving Payroll no later than 1600 GMT on its way to the Accounts Auditor.
Continue reading…

After dealing with requirements in all sorts of shapes and sizes over the years I find the “black box” approach works well. For requirements, I think of any system as if it were a black box.
Continue reading…

So how do you define requirement? I was working with a large hospitality corporation when I was asked this question. The problem is that the notion of requirement comes in many forms. The definition seems to depend on what role you play in relationship to requirements definition – Customer, Business Analyst, Systems Analyst, Designer, Architect, Developer, Tester, etc. Wikipeidia describes requirement as a statement of what a product or service does. IBM’s Rational Unified Process describes different levels of software requirements. They also use related concepts like need and feature. The Internaltional Institute of Business Analysts contains a definition from the Business Analysts perspective in their BA Body of Knowledge.

What is the hardest thing to estimate on a remodeling construction job? I asked a friend of mine who happens to be a contractor in the building trades. Not surprisingly he said it was estimating the hidden elements of the job. (Hmmm… software is mostly hidden)
Continue reading…