1. FdSc Module 107 Systems Analysis
Requirements
FdSc Module 107
Systems Analysis
These slides are based on Effective Project Management by Robert K. Wysocki, Wiley Publishing, Inc. 2009

2. Project Initiation Conditions of satisfaction meeting
A structured conversation between the client and the provider
Output is a one page document – the Project Overview Statement
This works well for smaller projects

3. Conditions of satisfaction example
Client : I would like you to build five prototypes of the new forest green widgets and ship them to my warehouse on December 1, 2009.
Provider: You are asking if we can get five green widget prototypes into your warehouse by December 1, 2009?
Requestor: Actually, if you can get them shipped by December 1, 2009, that will be acceptable. But remember they have to be forest green.
Provider: So if on December 1, 2009, I can ship five forest green widgets to your warehouse, you will be satisfied.
Requestor: Yes, but they must be the new model, not the old model.
Provider: The new model?
Requestor: The new model.
Provider: I believe I understand what you have asked for.
Requestor: Yes, I believe you do.

4. Conditions of satisfaction example
Provider: Because of my current production schedule and the fact that I have to change paint colours, I can ship two forest green widgets on November 25, 2009, and the remaining three on December 8, 2009.
Requestor: If I understand you correctly, I will get five prototypes of the new forest green widgets in two shipments — two prototypes on November 25 and three on December 8. Is that correct?
Provider: Not exactly. You won’t receive them on those dates. I will ship them to your warehouse on those dates.
Requestor: So, let me summarize to make sure I understand what you are able to do for me. You will build a total of five forest green prototypes of the new widgets for me and ship two of them on November 25 and the remaining three on December 8? You will of course use our agreed shipment schedule so that the items will arrive two days later.
Provider: That is correct.
Requestor: That will be acceptable.

5. Conditions of satisfaction
Both parties need to be very precise
At the end of the meeting both parties
have stated their positions
know that the other party understands their position

6. Success criteria These must be established at the COS
When the request will be satisfied
How the request will be satisfied
Preferably there are only two possible outcomes
It was successful
It wasn’t successful

7. COS activity
In pairs
One person is the client
The other is the supplier
Take the appropriate brief and hold a COS meeting
Produce a project overview statement

8. Requirements
For a small project the COS may be sufficient to get going
Larger projects require something more
Requirements gathering

9. Requirements
Requirements define the product or service that constitutes the deliverable
Requirements are the basis for defining the needs that the client is seeking to solve a problem or to take advantage of a business opportunity

10. Requirements types Functional requirements Non-functional requirements
Specify what the product or service must do
“allow a customer to place an order”
Non-functional requirements
demonstrate the properties that the product or service should have “use our existing branding”
Global requirements
describe properties of the system as a whole “the system must run on the existing network”
Product and/or project constraints
Such as budget, schedule, deadlines, regulations

11. Requirements gathering methods
Facilitated group sessions
Interviews
Observation
Requirements reuse
Business process diagramming
Prototypes
Use case scenarios

12. Facilitated group sessions
Strengths
Excellent for cross-functional processes.
Detailed requirements can be documented and verified immediately.
Resolves issues with an impartial facilitator
Risks
Use of untrained facilitators can lead to a negative response from users.
The time and cost of the planning and/or executing session can be high.

13. Interviews Strengths Risks End-user participation.
High-level descriptions of functions and processes are provided.
Risks
Descriptions may differ from actual detailed activities.
Without structure, stakeholders may not know what information to
provide.
Real needs may be ignored if the analyst is prejudiced.

14. Observation Strengths Risks
Specific and complete descriptions of actions are provided.
Effective when routine activities are difficult to describe.
Risks
Documenting and videotaping may be time-consuming and expensive, and may have legal overtones.
Confusing or conflicting information must be clarified.
Can lead to misinterpretation of what is observed.

15. Requirements reuse Risks Strengths
Requirements are quickly generated and refined.
Redundant efforts are reduced.
Client satisfaction is enhanced by previous proof.
Quality is increased.
Reinventing the wheel is minimized.
Risks
Requires a significant investment for developing archives, maintenance, and library functions.
May violate intellectual rights of previous owner.
Similarity of an archived requirement to a new requirement may be misunderstood.

16. Business process diagramming

17. Business process diagramming
Strengths
Excellent for cross-functional processes.
Visual communication through process diagrams.
Verification of ‘‘what is’’ and ‘‘what is not.’’
Risks
Implementation of improvement is dependent on an organization being open to changes.
Good facilitation, data gathering, and interpretation are required.
Time-consuming.

18. Prototypes Strengths Risks Innovative ideas can be generated.
Users clarify what they want.
Users identify requirements that may be missed.
Client-focused.
Early proof of concept.
Stimulates thought processes.
Risks
Client may want to implement the prototype.
Difficult to know when to stop.
Specialized skills are required.
Absence of documentation.

19. Use case scenarios (UML)
Strengths
The state of the system is described before the client first interacts with that system.
Completed scenarios are used to describe state of the system.
The normal flow of events and/or exceptions is revealed.
Improved client satisfaction and design.
Risks
Newness has resulted in some inconsistencies.
Information may still be missing from the scenario description.
Long interaction is required.
Training is expensive.

20. Generating Customer Requirements
Take the newsagents brief and work out a set of requirements
Classify, if possible, into :
Functional requirements
Non-functional requirements
Global requirements
Product and/or project constraints