Part 1: Using the best practices described in your book, perform one of the following techniques for helping to identify requirements: interview, questionnaire, observation, document analysis, or JAD session. Chapter 3, Requirements Definition in your book provides guidance. Write a 1-page document that describes the results/findings.
Part 2: We can classify most systems somewhere between BPI and BPR. You are to use both of the following techniques associated with BPI and BPR and include these in your system requirements document.
Benchmarking – What systems exist that are similar to yours? What will you incorporate from these systems into the design of your system? How will you make yours better than the competition? I suggest a feature comparison table that shows what features/benefits your system has compared to your competitors, along with a written summary of the table.
Outcome analysis – Discuss with your team what value your systems will deliver to your users. Write a 1-page document describing the outcome(s) of this system that will provide value to potential users. Don’t describe the technology or the features. Talk about what the users ultimately want (i.e., to reduce information overload, organize information, connect to people). Remember the axiom: “Our customers don’t want drill bits. They want holes.” The outcome analysis is a document focusing on the hole, not the drill bit. Part 3 focuses on the drill bit...
Part 3: Building on Parts 1 and 2 above, expand on your project scope document by describing the functional and nonfunctional requirements for the system (i.e., what it must DO or enable a user to DO). See Chapter 3, Defining a Requirement section of your book for guidance, especially Figure 3-2. Seriously, re-read your book on this one. A lot of teams get this wrong the first time around. They don't understand functional and nonfunctional requirement. Seek clarity.