IS 341

Business Systems Analysis

Chapter 5 - Notes

Determining System Requirements

 

NOTE:  this text breaks up the Analysis phase into 2 sub-phases:  Requirements Determination, and Requirements Structuring (developing Data Models and Process Models); this chapter deals with Requirements Determination

 

I.  Performing Requirements Determination – deciding what the new system should do – this means understanding the old system’s capabilities and limitations

          A.  The Process of Determining Requirements

                   1.  Impertinence – question everything!!

                   2.  Impartiality – be non-partisan; your job is to find the best solution/opportunity, not to take sides

                   3.  Relaxing of Constraints – assume anything is possible, then eliminate the infeasible (what cannot be done)

                   4.  Attention to Details – all the facts must fit properly

                   5.  Reframing – analysis is also creative, look at things in new ways and from different viewpoints and frameworks

          B.  Deliverables and Outcomes – the deliverables here are the information that is gathered in the process, anything the analysts collect

          C.  Requirements Structuring – the amount of info gathered in during Requirements Determination may be huge (depending on the project scope), and the time required to collect and structure this information can be very extensive and expensive.  The text notes that most systems analysts today focus more on the system being developed than on analysis of the current system.  However, the text does not mention the very real danger of missing important issues by ignoring the current system (those who fail to study history are doomed to repeat it).  The more time you spend analyzing/understanding the current system, the more successful will be the new system.

                   Analysis Paralysis – getting bogged down in too much information (a very real danger, but remember the dangers of not doing enough analysis – deal with it!)

 

II.  Traditional Methods for Determining Requirements

          A.  Interviewing and Listening – expensive and time-consuming; lots of information given; be careful to hear what is said/meant, not what you want to hear

                   1.  Choosing interview Questions – Open- or Closed-Ended

                             a.  Open-Ended – when you cannot anticipate all possible responses, or do not know the precise questions to ask;  the interviewee can just chat on & on about the subject, no boundaries

                             b. Closed-Ended – you specify the allowed answers in advance, only certain specified answers are permitted [true/false, multiple choice, rate a response on a scale (e.g., 1-10), ranking in order of importance]

                   2.  Interview Guidelines – do not lead the person with questions that suggest they answer a certain way; avoid questions that imply right or wrong; avoid negative or confusing questions; avoid technical terminology with which the person may be unfamiliar

          B.  Administering Questionnaires NOTE:  the Questionnaires section does not appear in edition 5 of the text; it is included here for informational purposes

                   1.  Choosing Questionnaire Respondents – be careful to get a valid sample!

                             a.  Those Convenient to Sample – this easily leads to a poor sample

                             b.  A Random Group – every nth person

                             c.  A Purposeful Sample – those who satisfy certain criteria

                             d.  A Stratified Sample – random selections from various categories

                   2.  Designing Questionnaires – should be easily administered, sometimes without a person to administer the form (e.g., over the Internet); usually closed-ended questions; watch out for “Never” & other limiting or negative words

          C.  Choosing Between Interviews and Questionnaires – depends on the situation, available resources, and the type and amount of data required

          D.  Directly Observing Users – people are not always reliable, so you can Watch what they do instead of asking them; however, people perform differently when being watched

          E.  Analyzing Procedures and Other Documents – you can learn from looking at an organization’s formal procedures and other documentation

 

III.  Modern Methods for Determining System Requirements

          A.  Joint Application Design – developed by IBM in the late 1970s to bring together stakeholders involved in analysis of a current system; has a Leader, an Agenda, Scheduled Date/Times, and Time Limitations

                   Taking Part in a JAD

          B.  Using Prototyping During Requirements Determination

                   1.  Prototypes – a working model of a system to show/demonstrate certain characteristics of the proposed system

                   2.  Type I Prototype – a working model that starts small and grows a little bit at a time until the model becomes the actual system; time consuming, but very satisfactory for the user who gets what he wants

                             Strengths – better communication with the user

                             Weaknesses – time consuming

                   3.  Type II Prototype – a throw-away model that shows certain features but is not usually written in a full programming language; typically, prototyping languages are used that shot-cut the development process; once the features are approved, the prototype is thrown away and development proceeds in a full programming language; dangerous if users are not consulted regularly, or if the system is delivered in a prototyping language (to shortcut development time)

                             Strengths – expedited delivery time for the system (saves time)

                             Weaknesses – unrealistic expectations on the part of the user (analyst must manage user expectations!)

                   4.  Prototyping is useful when:

                             a.  user requirements are not clear

                             b.  small numbers of stakeholders are involved

                             c.  possible designs are complex and a concrete form helps evaluation

                             d.  communication problems exist and something is needed to make requirements as specific as possible

                             e.  tools and data are available to help build systems quickly

                   5.  Drawbacks to Prototyping:

                             a.  may promote a tendency to avoid creating formal documentation

                             b.  may be idiosyncratic for initial users and difficult to diffuse or adapt to other users

                             c.  may be built as stand-alone applications and not interact well with other systems

                             d.  may bypass checks built into the SDLC, and may mistakenly bypass important system requirements

 

IV.  Radical Methods for Determining System Requirements

                   Business Process Re-Engineering – replacing current systems with new systems that may be radically different from the original systems

                             1.  Re-Structuring

                             2.  Reverse Engineering

                             3.  Re-Engineering

          A.  Identifying Processes to Reengineer – find and understand key business processes

          B.  Disruptive Technologies – those that enable the breaking of long-held business rules that inhibit organization from making radical business changes

 

V.  Pine Valley Furniture WebStore:  Determining System Requirements

                   1.  System Layout and Navigation Characteristics

                   2.  WebStore and Site Management System Capabilities

                   3.  Customer and Inventory Information

                   4.  System Prototype Evolution