1 / 23

Systems Development Life Cycle

Systems Requirements Determination. Heading into detailed analysis phase we need to think about what the system must do to satisfy usersCollection of Processes or Objects?Traditional view: System is a collection of processes that require data as input and produce data as output. OO view: System is a collection of objects that interact with each other and the end-users. Objects are capable of certain behaviors (methods) and store their own data.We'll use the process orientation but touch on OO later..

dana
Download Presentation

Systems Development Life Cycle

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


    1. Systems Development Life Cycle

    2. Systems Requirements Determination Heading into detailed analysis phase we need to think about what the system must do to satisfy users Collection of Processes or Objects? Traditional view: System is a collection of processes that require data as input and produce data as output. OO view: System is a collection of objects that interact with each other and the end-users. Objects are capable of certain behaviors (methods) and store their own data. We’ll use the process orientation but touch on OO later.

    3. Three Types of System Requirements Functional Describe system-environment interaction Logical not physical Implementation independent The system must display local time based on workstation locale Non-functional Visible to user but not functional The system must process all requests in less than 2 seconds Constraints Imposed by client or system environment Often lead to sub-optimal development The system must be programmed in C++ The system must be compatible with the existing MRP

    4. The Three I’s of Requirements Impertinence Taking nothing for granted Ask questions: “Is this always true?” Impartiality Consider all stakeholder concerns and look for “best” solution Insight Greenfield mindset (Butlerville) Attention to detail Creativity! VFT

    5. Requirements Determination Mistakes Assuming a functional system As opposed to a cross-functional system Users can rarely see outside of their silo Identify all stakeholders and affected parties Systems should be viewed as business problems not functional area problems This could (should?) increase the scope! technology can support the entire value chain re-negotiate as needed

    6. Requirements Determination Mistakes Collecting requirements from individual end-users and not the whole group Often fails to identify all of the issues At best can prolong the requirements process Bottom line: most users have similar problems and it may help spark their memory to have a group session Groupthink? There may be times when a F2F is the best way to go.

    7. Requirements Determination Mistakes Asking the wrong questions “What kind of surgery would you like today, Ms. Patient?” All too often the user thinks he/she knows what they need Trying to make the interviewer happy Bad interviews! Failing to allow refinement through trial and error In SAD, iterative prototyping can be useful RAD Throwaway or Evolutionary?

    8. Getting Requirements

    9. Good Requirements are …

    10. Testable?

    11. Traditional Information Gathering

    12. Pros Analyst can motivate the respondent to answer freely and openly. Respondent develops a sense of active contribution to the proposed system. Analyst can probe for additional information Questions can be restated for better clarity or to facilitate mutual understanding. Analyst can easily observe nonverbal communication channels such as body language Cons The interview process is time-consuming and resource intensive. Interview success is highly dependent on the communication skills of the analyst Confirming vs. Disconfirming Geographical location of the necessary respondents may make the interview process impractical. Direct Interview

    13. Man with a Plan?

    14. Open Minded? Open or Closed Questions PROS Open : increase spontaneity; richer responses; easier to create; keep respondents interested Closed: decrease time required; more interview control; easy to compare answers across participants CONS Open : irrelevant details; loss of control of interview; more time required; “fishing expedition” Closed: boring; less “bonding”; less information content; easier to miss important information Best to mix it up

    15. Managing the Interview Process Be careful to avoid phrasing a question so that a right or wrong answer is suggested or implied. Have you stopped beating your wife? Remember to listen, listen, and listen. Notes and tape record if possible. Schedule interviews with a variety of users and managers that represent the widest possible set of perspective. Outside the silo Analyst must manage the expectations of respondents Debrief within 48 hours

    16. Focus Groups Group of respondents

    17. Questionnaires and Surveys Pros Questionnaires can often be answered in less time. Respondents can answer questions at their convenience. Responses can be easily tabulated and analyzed. Questionnaires allow for respondents to maintain anonymity. Cons Response rate is often low. Less flexibility than other, more direct methods. No guarantee that respondent will answer all questions No direct observation of the respondent during questioning. Questionnaires are often time-consuming and difficult to prepare. No opportunity to clarify points or expand on topics covered.

    18. Survey Design Reliability (consistency) External : same results across administrations; repeatable Internal : will subject respond same every time? repeat questions Validity The survey obtains the desired information Right questions? Right respondents? Pilot studies Face validity of questions (security survey) Ease of use Understandable, short, logical ordering / grouping

    19. Scales Measuring a characteristic or attribute of respondent? Nominal Scale Which best describes your primary work responsibilities? Ranking/rating of an issue? Ordinal Scale Classify and/or rank order Always sometimes, never Interval Scale On a scale of 1-10 Equal intervals Ratio Scale Equal intervals and a “0”

    20. Sampling Scope of Data Type and amount Identify the Population Determine Sample Characteristics Convenience Sample : No criteria; non-Random selection Simple Random Sample : No criteria; Random selection Purposeful Sampling : Criteria; non-Random selection Complex (Stratified) Random Sampling : Criteria; Random Sample Size

    21. Direct Observation People may not be able to accurately recount their actions or feelings Happens infrequently; blinded by what “should” happen Can be very insightful, but must be planned You get a snapshot or reality Very time consuming Observer bias Hawthorne Effect Use both obtrusive and unobtrusive mechanisms

    22. Archival Document Analysis Review all documentation of current and proposed system Organizational Mission Statement Organizational Charts Stakeholders and decision rights Job Descriptions Financials Policies and Procedures Forms Analysis Data requirements Current System Documentation

    23. Traditional Information Gathering

    24. Modern Methods for Requirements JAD Very structured focus group Several hours – Several days Interaction leads to sense of common ownership Can shorten or focus information acquisition Find discrepancies in stakeholder views Iterative Prototyping (RAD)

More Related