Steve Easterbrook,
Associate Professor, University of Toronto

Steve Easterbrook has worked on the problem of negotiating conflicting requirements for large software projects. His experience includes teaching at the School of Cognitive and Computing Sciences at the University of Sussex, UK and working as head of the Research Lab at NASA's Software Verification Facility. He is currently an Associate Professor in the University of Toronto’s Computer Science department.

He has published over 40 papers, edited a book on Computer-Supported Collaborative Work, and serves on program committees for major international conferences in requirements engineering. He was the General Chair of the 2001 international RE conference in Toronto.

According to the RE 2001 conference Web site, “Requirements Engineering lies at the heart of software development. RE is concerned with identifying the purpose of a software system, and the contexts in which it will be used. Hence, RE acts as the bridge between the real world needs of users, customers, and other constituencies affected by a software system, and the capabilities and opportunities afforded by software-intensive technologies.”

Requirements engineering generally applies to software. We generally notice if a highway doesn’t join Point A to Point B or if a bridge is shaky. But software is a structure of thought and logic, and it can be hard to tell until late in its development whether it’s doing the right job. Therefore, RE—being clear about what you’re building and what constitutes being finished—has many issues and approaches.

As technical communicators, we are greatly affected by the problems addressed by Requirements Engineering (RE). Our work goes better or worse depending on whether developers have a clear and consistent view of their goal. We are in a position to promote good requirements.

Some of of the problems are defining your terms or information that is missing, ambigious, or misinterpreted. But one of the main problems is that specifications change as software is developed. Requirements almost inevitably evolve; but that does not mean that we give up and say it’s impossible to produce a clear and detailed requirements specification. Indeed, requirments may change throughout the life cycle of the software, and that is yet another issue to be addressed: beyond development.

Click here for a PDF version of his slides for at the May meeting. This is a large file, 1.5 megabytes.

See Steve Easterbrook's Web site for Interesting stuff like this:

• There's a difference between the requirements for a system and the software requirements that people extract from them, which then drive what gets produced. Important things get lost if the people spec’ing the software don't know what the system requirements are for and why they're important. The first example was a little misunderstanding about what the requirements what the Mars Polar Lander were supposed to accomplish, which resulted in the complete failure of the mission at a cost of $165 million U.S. dollars.
• A single project can have requirements (e.g. being cheap and fast) that conflict with longer-term requirements (e.g., being able to find out WHY something failed so you can avoid that failure next time). He says it's basically a communications problem rather than, say, an engineering problem. Technical writers can help!

The site has slides from various presentations, including what if your clients can't agree about what they want, how to handle changing requirements, and so on. Useful for anyone who's doing a project and especially software ('cause it's invisible).