Posts Tagged ‘requirements’

  

The Two Domain Problem

Most professions and trades only need to know their own domain of practice, not the customers. When you see a dentist or a plumber they do not need to understand what you do in order to work on your teeth or your plumbing. Software development is different: its essence is the automation of work. So […]

Alternatives to Formal Traceability

In my prior post The Trouble with Traceability I discussed the problems with doing requirements traceability, especially formal traceability using approaches like a requirements traceability matrix (RTM). Despite the flaws with traceability the underlying objective is sound: ensure that everything the customer or user requires is correctly delivered. So how can we achieve this objective? […]

The Trouble with Traceability

In software development traceability is the linkage of requirements to the software and/or development artifacts like design or test cases. The underlying objective is to ensure that everything the customer or user requires has been correctly delivered. I have no quibbles with this goal, but in practice the applications of traceability I have seen leave […]

Example-Based Requirements

Most of the requirements I deal with are in the form of documented use cases and lists of business rules. These requirements are almost always written in a generalized form. For example a business rule might be written as “Produce a warning if the last transaction in the account is more than a year ago.” […]

Defect Prevention Practices

I have written numerous times about defect elimination practices such as code reviews, unit testing, and static code analysis tools. From the perspective of lean thinking, however, eliminating defects, no matter how soon after they are introduced, results in waste due to rework to fix the defects. The ideal as far as lean is concerned […]

Inspiring Great Design

I recently acquired a design tool – a set of IDEO method cards, where each card presents a design approach or a method of gaining inspiration. IDEO’s design philosophy is to keep people at the center of the design process, and the four categories they divide the cards into reflect this: Ask people to help. […]

Producing Good Software is Hard

This is a public service announcement to all project managers, business analysts, others working in the I.T. industry, and the general public: producing good software is hard. The next time you wonder why the software you are using crashed, or why your software development project is behind schedule, or why your software doesn’t meet the […]