Semantic Classification of "Systems Analysis & Design" Resources

This document represents information from Griffith Uni's "Systems Analysis & Design" course (created by A.Pr P. Deer): the text below contains and structures the content of about 350 of the 437 slides of the course (e.g., the content of examples via figures and tables has not been represented and the redundancies which were necessary for presenting the content via slides have been eliminated and so was the content refering to tutorials and examinations). The FL notation is used. (Information/relations that are not of direct interest to students have been hidden using HTML comments below but these relations are displayed when querying/navigation is done).

These representations have been loaded into the WebKB-2 knowledge base. Statements are in the courier font. They are enclosed within the XHTML marks <KR> and </KR> to permit WebKB-2 to distinguish them from regular text.   To navigate from one of the categories below, copy-paste its identifier (term with '#' inside) into the following textbox or use the provided hyperlinks. Then, use the search options at the end of each displayed page.


Reminder: statements of the form "CONCEPT1 subtype: CONCEPT2 CONCEPT3" should be read:
"CONCEPT1 has for subtype CONCEPT2 and CONCEPT3" (in other words, any instance of CONCEPT1 is also an instance of CONCEPT2 and CONCEPT3). For relations other than "subtype" and "supertype", "CONCEPT1 RELATION1: CONCEPT2 CONCEPT3, RELATION2: CONCEPT4;" should be read: "any CONCEPT1 may have for RELATION1 one or many CONCEPT2" and "any CONCEPT1 may have for RELATION1 one or many CONCEPT3" and "any CONCEPT1 may have for RELATION2 one or many CONCEPT4".

Table of contents

Domains and Objects

 subdomain of: #information_science,
 object: is#course_of_system_analysis_and_design

   is#course_of_systems_analysis_and_design   supertype: #course,
    subtype: gu#1015INT  gu#7007INT;

 definition: "business objectives that drive the work"
             "policies describing the nature of the business, the market, and the
              environment it operates in"
             "rules and processes governing business practice"
             "data storage and processing requirements"
             "order, timing and impact of key events",
 subtype: is#project_outcome_requirement;

   subtype: is#project_deliverable,
   definition: "what we want to achieve/produce"
               "what does the business do (and why, and how)?"
               "what does it want to do (and why, and how)?"
               "what will our information systems need to do to address these?";

     definition: "information from interviews, questionnaires, notes, minutes ..."
                 "various existing information documents - business objectives,
                  procedures, forms, reports, requirements collected during operation
                  of existing systems ..."
                 "computer-based information - screenshots, prototyped forms, design 
                  of existing database or process applications ..."
                 "requirements documentation!";

Properties, Measures, Models and Laws

 subtype: {is#tangible_cost  is#intangible_cost}  {is#startup_cost  is#recurring_cost}
          {is#project_development_cost  is#project_operational_cost};

   annotation: "time dependency of recurring benefits and costs: 
                a dollar today is worth more than a dollar tomorrow,
                costs change e.g. interest rates, inflation, Moores Law, currency fluctuations,
                benefits can decay or increase over time";

   annotation: "staff salaries, equipment and installation, software and licenses,
                consulting and other third party fees, training, facilities,
                utilities and tools, support staff, travel and misc expenses";

   annotation: "hardware and software maintenance and upgrades, connectivity costs,
                programming, 'Management' overhead (including change requests,
                configuration control, documentation), sysadmin and 'helpdesk' support,
                training, consumables";

Processes, Tasks, Techniques and Methodologies

 subtype: is#system_analysis_and_design_task
 agent: is#system_analysis_and_design_agent;

   subtype: is#task_of_traditional_system_development_life_cycle
            is#rapid_application_development  //prototyping approach
            is#end-user_project_development  is#evolutionary_project_development,
   annotation: "there is no 'best way'; choose the 'most appropriate way', being mindful 
                of the strengths and weaknesses of each";

Planning and Managing Projects (Week 2)

 annotation: "why, what, when, where, who and how",
 part: is#project_initiation_and_planning  is#project_execution  is#project_close_down,
 input: is#project_requirement,
 object: #project;

   successor: is#project_identification_and_selection  is#project_analysis,
   definition: "establishment of scope, feasibility and resources",
   output: "statement of work (an overview for the 'customer')",
   subtype: is#project_initiation  is#project_planning;

     part: "addressing the most important 'why'" 
           "establishing of initial resources, team, resources, ..."
           "creating plans (initiation, scoping and/or feasibility studies, ...)"
           "management procedures, customer relationships, project workbook,
            environment (influenced by development model options), ...";

     part: is#project_feasibility_assessment  is#project_resource_usage_estimation
     annotation: "defining scope, feasibility, alternatives"
                 "project schedule, detailed resource estimating and planning"
                 "various plans (communications, test, ... )"
                 "standards and procedures, risk assessment"
                 "detail of agreed development models, management procedures and environment",
     output: "statement of Work (an overview for the customer)" is#baseline_project_plan
             "project review and decision on whether or not to proceed, and how";

   definition: "execute and manage your plan, with all the attendant resource, personnel,
                monitoring, organisational and technical change management, communication, 
                QA and documentation issues";

   definition: "transition to either: operation, oblivion, 
                reviews of project management or the project itself,
                people, resource, contractual and numerous other issues";

Estimating the Feasibility of Projects (Week 3)

 annotation: "criteria: economic, technical, operational, schedule, legal and contractual,
              political (organisational and cultural)",
 subtype: is#project_economic_feasibility_assessment

   annotation: "an assessment of financial benefits and costs associated with the project"
               "must identify and quantify benefits and costs at least to the point where
                meaningful comparisons between projects can be made",
   part: is#cost/benefit_analysis  is#cash_flow_analysis,
   method: is#project_economic_feasibility_assessment_technique;

     annotation: "usually needs to consider the cash flow issues of economic feasibility 
                  i.e. when is money needed, or when does it become available";

     subtype: is#net_present_value_analysis  is#net_present_value_analysis

      is#net_present_value_analysis__NPV_analysis  //the "__" means "synonym:"
       definition: "converting the future dollar amounts of costs and benefits into their 
                    current value, and compare the current values";

       definition: "analysing the benefit achieved per dollar of cost";

       definition: "analysing the amount of time required for the cumulative value of 
                    benefits to equal or exceed the cumulative costs";

   issue: "Does it require a research breakthrough?"
          "Does it introduce new development technology?"
          "Does it introduce new application technology?"
          "Is it a large and complex project?"
          "Are we likely to be short of the people we need (skills and numbers)?"
          "Is there a low level of structure and understanding of the business 
           processes and requirements?";

   annotation: "related to technical and organisational feasibility in many models"
               "concerned with extent to which proposed system will meet organisational
                goals and its effect on structures and processes";

   annotation: "can we meet the development milestones? A simple test is: Did you 
                developed the schedule without regard to externally imposed constraints
                and deadlines? If NO, you must consider the schedule to be a high risk
                component of your project";

   annotation: "legal E.g. copyright, nondisclosure, financial reporting, misc minor legislation"
               "contractual E.g. development/testing/documentation requirements";

   annotation: "how do various stakeholders (both within and without the organisation)
                view the proposed system?"
               "Issues: computer competency, perceived shifts in control and power,
                concerns about job security and prospects, changes to established
                procedures and responsibilities";

Estimating the Resource Usages (Week 3)

 annotation: "gather a consensus: a mean or median of estimates from a number of people
              will usually prove more accurate than a single estimate, e.g. the 
              DELPHI method",
 trap: "optimistic estimation"  "the 'Mythical Man Month' problem"
       "the bill for documentation, testing and training"
       "pressures to estimate in conformance with desires and the 'can do' problem"
       "allowing your estimate to be treated as an opening position in a negotiation 
       process"  "the idea that 'we will make up this phase' slippage in subsequent phases"
       "the effect of changes in scope or requirements",
 subtype: is#project_cost/benefit_estimation

   method: is#project_amount_of_work_estimation_technique;

     subtype: is#project_decomposition  is#project_estimation_via_an_estimation_model

       definition: "breaking the task into smaller subtasks, and estimate each individually";

       annotation: "various modeling environments to help predict work requirements"
                   "tend to be highly proprietary and somewhat secretive"
                   "uses numerous different input parameters"
                   "from input parameters, predict resource usage and development effort"
                   "Eg. Constructive Cost Model: COCOMO, Boehm 1981";

       annotation: "essentially, a modeling technique"
                   "determine number of function points: inputs, outputs, internal files,
                    external files, system query environments"
                   "look up history of prior projects with comparable function points";

Traditional Tasks of Information System Development (Week 4)

 annotation: "the SDLC is more aligned with corporate management models than  
              other system development methods are"
             "there are many Standard Model for Traditional SDLC but when we look closely
              into these, there are far fewer differences than similarities",
 subtype: is#project_identification_and_selection
          is#project_initiation_and_planning  //detailed in a previous sub-section
          is#project_analysis  is#project_analysis_subtask
          is#project_design  is#project_implementation_and_maintenance,
 output: "a functional system (software, hardware, procedures, trained users)"
         "documentation about the system itself (specifications), about the 
          development process, about the use of the system (procedural manuals,
          user guides and training manuals)";

   successor: is#project_initiation_and_planning,
   successor of: is#project_maintenance,
   output: "mandate to continue to the NEXT PHASE"
           "commitment of the resources necessary for the next phase only!"
           "identification and selection of needs (ideally, a whole-of-enterprise
            analysis e.g. SWOT), priorities, resources"
           "decision on what to proceed with",
   subtype: is#project_identification  is#project_selection;

     annotation: "how do potential development projects arise?"
                 "top down (usually focuses on supporting what we want to do)"
                 "bottom up (usually focuses on supporting what we currently do,
                  and how we currently do it)"
                 "from the IS Department (usually focuses on improving efficiency
                  of IS support)";

     annotation: "to select, we must assess/classify/compare/rank projects via criterias:
                  value chain analysis, strategic alignment, preliminary assessment of
                  various aspects of feasibility, ...";

   successor: is#project_initiation_and_planning  is#project_logical_design,
   annotation: "detailed study of needs, current procedures and information systems",
   requirement: "the organisation has identified a number of potential projects and selected one"
                "some work effort has already gone into identifying the project, scope,
                 feasibility, budget and broad total work effort i.e. Planning"
                "the Senior Management has reviewed the project, and given approval to proceed",
   part: is#project_analysis_subtask; 
     subtype: is#determining_project_requirements  

   part: "addressing how we intend to do and represent it"
         "addressing: system interfaces and interactions, database design,
          program and module design and specification, system architecture",
   subtype: is#project_logical_design  is#project_physical_design,
   output: "detailed system specifications";  

Analysis - Determination of Requirements (Week 5)

 output: is#project_requirement,  //detailed in the first section of this document
 method: is#traditional_method_of_requirements_determination

   subtype: is#interviewing  is#using_questionnaires  is#direct_observation

     guideline: "plan the interview - individual or group, who, consider desired outcomes,
                 recording/documentation, followup and feedback processes, ..."
                "prepare! - both yourself and the interviewee: when, where, for how long,
                 what you will be asking, design interview form ..."
                "listen and 'record' (you are there to find out their views, not express
                 your own!), and document as soon as possible"
                "take care about raising expectations (and the problem of 'active listening')"
                "allow adequate time between interviews for documenting, redesigning interview etc"
                "'close the loop'",
     object: is#interview; //see details below in the data/document structure section

     object: #questionnaire,
     annotation: "generally more 'efficient' than interviews but less rich in information
                  response" "generally tend towards more closed questions",
      requirement: "need greater care to avoid ambiguity or biased sampling";

     rationale: "there is often a significant disparity between what people think they do
                 (or would like you to believe that they do) and what they actually do
                 (and how they do it); direct observation can detect this and other 
                 inadvertent omissions",
     requirement: "for direct observation to work effectively, you will need to be
                   more than a passive observer (but beware of the observer influencing
                   the observed!)"  "plan observation to avoid bias (e.g. different people,
                   different levels, different times)";

     subtype: is#analysing_existing_business_documentation;

       definition: "analysing mission statements, organisational objectives, business plans,
                    organisational charts, duty statements and job descriptions,
                    procedural manuals, training manuals, business forms,
                    current system design documentation, ...",
       requirement: "beware of the difference between formal/informal systems and processes!";
   annotation: "generally, we embark on these when entering new and/complex areas, 
                when we think the processes and requirements are not well understood, when
                we need to re-think not only how we do things, but what we do, and why",
   subtype: is#Joint_Application_Design  is#requirements_determination_via_prototyping;

     annotation: "structured meeting involving representatives of all stakeholders"
                 "objective - to collect requirements"
                 "supported by some computer tools, such as CASE groupware products
                  (but can use variety of general support software)";

     annotation: "various types ranging from simple forms to full functional prototypes"
                 "even with simple prototypes, we want to investigate process, not just 

Analysis - Structuring of Requirements (Week 6, 7 and 8)

 subtype: is#process_modeling  is#data_modeling  is#logic_and_timing_modeling,
 object: is#project_model,
 input: "information from Requirements Determination";

   annotation: "what processes exist (i.e. what does this system actually do, and how does
                it do it)? what information do these processes use or produce?",
   object: is#process_model;

   annotation: "detail the data definitions, structure or relationships"
               "needed for the design of programs, data bases, forms, reports etc"
               "starts with a data model of the existing system (not information system!)
                and supplement with other information from Requirements Determination";

   annotation: "represents the internal structure and functionality of a process",
   requirement: "must be complete and detailed"
                "must be generic, i.e. not represent specific syntax of a product/environment",
   instrument: is#logic_and_timing_model; 

Analysis - Generating and Selecting Design Strategies (Week 9)

 subtype: is#generating_project_design_strategies  is#selecting_project_design_strategies,
 output: is#project_design_strategy;

   subtype: is#minimalist_design_strategy is#maximalist_design_strategy
   definition: "high level statement about our approach to developing a system",
   annotation: "deals primarily with: scope and functionality, method of acquisition, and
                implementation environment";

   definition: "identifying strategy alternatives is needed to investigate what is 'best'
                for the organisation, what can it manage at this time, what does it
                want to do in the future, ..."
                "identifying strategy alternatives is needed to avoid re-design efforts
                 later, misunderstanding about the goal of the project, ...",
   requirement: "must consider: system features, information needs, functionality, 
                 modes of output, timeliness, development constraints, timeframe,
                 organisational commitment, resources, business environment issues";
   annotation: "focus on a small number of feasible alternatives (because we need to 
                analyse and describe these in detail)"
               "the 3 most common alternatives will represent (at least in terms of
                scope and functionality, and usually environment):
                1) minimum, 2) maximum, 3) realistic compromise",
   subtype: is#selecting_the_best_project_design_strategy;

     requirement: "any alternative selected to be the best must: (i) adequately address at 
                   least the minimum requirements, (ii) be technically and financially
                   feasible with attractive total cost of ownership, (iii) meet the 
                   organisation's timeframe requirements",
     method: is#cost/benefit_analysis  is#weighted_assessment_criteria_method
     agent: "the organisation/business with advice from PM, Analysts and/or IT Management",
     successor: is#updating_the_baseline_project_plan;

       object: is#baseline_project_plan;

Logical Design (Week 10)

 successor: is#project_analysis  is#project_physical_design,
 successor of: is#project_physical_design,
 part: is#designing_forms_reports_and_interfaces  is#logical_database_design,
 annotation: "what is this system going to do: system functionality, process support, ...?"
             "describing a solution without regard to physical implementation issues,
              limits and constraints (business level representation of how requirements
              will be met with a solution)",
 rationale: "those who build it probably won't have been involved in designing it (and
             those who maintain it will be different again, and those who design and
             build its replacement will be different again)",
 output: "justification or explanation"
         "a narrative overview (essentially the who, what, when, where, why, how etc)"
         "design itself (sample?)"  "information testing and assessment";

   requirement: "based on user and task requirements"
               "needs to address: who, what, when, where, why, how etc"
               "feedback on design from users (prototype?)",
   object: is#form_created_by_project_design  #report  #user_interface,
   guideline: is#report/interface_general_formatting_guideline;

     annotation: "the data elements of the form or report relate to components of 
                  data stores and E-R data models";

     subtype: is#user_interface_design_principle,
     purpose: "for achieving consistency, efficiency, speed, accuracy, satisfaction,
               ease of use, ...",
     #measure: "time to learn, speed of performance, error rate, retention, satisfaction",
     instance: "highlighting, colour, use of text, table or graphical presentation"
               "do not undervalue 'common look and feel'"
               "be careful of inducing or reinforcing bias (both theirs and your!)"
               "provide assistance to users (error and valid response checking,
                selection menus, 'default' responses, help files, maybe speech recognition,
                dictionary and thesaurus services)";

       object: #user_interface,
       subtype: is#consistency_oriented_user_interface_design_principle

         example: "present common functions using the same interface";

         example: "allow for interactive discovery"  "allow for trial and error"
                  "allow user to undo what has just been done";

         example: "confirm the system is responding to input"
                  "a user interface should be timely and near the point of activity";

   part: is#relational_database_normalisation
         "represent entities (identifier becomes primary key, other attributes become
          non-key attributes of the relation)"
         "represent relationships (e.g. the primary key of one relation becomes a foreign key of another)"
         "normalise relations"  "merge (and re-normalise) relations (if appropriate)",
   object: is#logical_data_model,
   output: "a normalised data model of our system that conforms to our chosen database
            technology (commonly, relational)";

     subtype: is#relational_database_normalisation_in_3NF;

       object: is#relational_database_third_normal_form__3NF,
       output: "every nonprimary key attribute depends upon the whole primary key,
                and nothing but the primary key";

Physical Design (Week 11)

 successor: is#project_analysis  is#project_physical_design,
 annotation: "how the system is going to meet the requirements (choice of language 
              and development environment, physical infrastructure choices, ...)?"
             "maps the Logical Design to the implementation environment",
 output: "technical specification of how solution will actually be physically implemented",
 subtype: is#physical_file/database_design  is#system_and_program_structure_design
 object: is#system_structure  is#program_structure  is#system_architecture;

   purpose: "translate the logical database design into technical specifications for implementation",
   part: "defining attribute data types (fields)"
         "determining the physical record structure"
         "organising files for secondary storage devices"
         "selecting and allocating the storage databases and devices",
   object: is#physical_file  is#system_structure is#data_schema  is#physical_data_base 

   definition: "group the system processes (modeled by Data Flow Diagrams) into modules
                (a module is a relatively small functional unit of a system, with high
                 cohesion and low coupling; commonly represent using Structure Charts)",
   guideline: "modular and hierarchical"
              "each module should control a small number of subordinate modules"
              "each module should be relatively independent (low coupling)"
              "relatively cohesive (one function)" "relatively small in size"
              "as generic as possible",
   output: is#output_document_of_program_design;

   part: "choosing a network architecture (homogeneous/heterogeneous networks; 
           applications - distributed, client/server, central server etc)"
         "managing data (file servers, distributed or replicated databases,
          how to ensure integrity and security)"
         "separating application and data through middleware technology?";

Implementation and Maintenance (Week 12)

 part: is#project_implementation  is#project_maintenance  is#security_management,
 annotation: "implementation and maintenance are the two largest, longest and most 
              expensive phases";

   successor: is#project_physical_design  is#project_maintenance,
   purpose: "to convert system specs into functioning and reliable system, with 
             documentation and adequate support services",
   annotation: "second largest and most expensive phase"
               "largest number and widest variety of personnel involved",
   subtype: is#coding  is#testing  is#documenting_the_project_implementation

     definition: "coding turns the physical design specs into functional computer code",
     part: "documenting while coding"
           "many programmers, many modules, many changes -> how to keep track? 
            importance of module libraries and revision control";

     annotation: "testing approach and procedures are formulated before implementation starts",
     output: is#master_test_plan,
     part: is#quality_assurance;

       part: is#unit_testing  is#integration_testing  is#system_testing

         agent: is#programmer,
         part: "testing a module or subportions as the coding progress"
               "checking at completion that it meets the specification requirements"
               "technical walkthroughs";

         agent: "the IT section",
         object: "all the modules together (do they co-operate correctly as a system?)",
         requirement: "usually requires separate environment and data"  "migration procedures";

         agent: is#user,
         definition: "tests the system is acceptable as far as the users are concerned:
                      Does it do what the users want (functionally)? Does it fail-safe
                      and recover? Is it robust and tolerant of user errors? Is it secure?
                      Does it meet performance requirements?",
         annotation: "separate acceptance test environment and data";

     definition: "review and update business documentation made during the analysis and 
                  design phases",
     object: is#documentation_of_the_project_implementation;  //details in a section below

     part: is#user_training_related_to_an_IS_implementation
           "notify customers of changes and help them adapt";

       part: is#file_back-up_and_recovery  is#data_file_maintenance;

     part: is#technical_support_related_to_an_IS_implementation

       part: "help with machine usage"  "assist with operating system problems";

       part: "assist with system usage" 
             "can also act as job initiation point for tech support";

     part: "transferring from the 'old' system to the new"
           "hardware and network rollout"
           "software rollout or migration",
     method: is#direct_installation_of_an_IS  is#parallel_installation_of_an_IS 
             is#phased_installation_of_an_IS  is#pilot_installation_of_an_IS;

       part: is#data_conversion  is#data_mapping  is#data_cleansing  is#data_transfer

       part: "complete old to new system transfer",
       characteristic: "highest risk" "one time for whole of organization"
                       "minimum transfer effort";

       part: "run old and new together until management deems old can be eliminated",
       characteristic: "minimizes risk"  "requires greater effort and resources";

       part: "change from old to new incrementally"  "start with some functionality"
             "continue in portions until all functionality 'transferred' to new system";

       part: "try out the new system at one location"  "evaluate system readiness";

     requirement: "successful implementation",
     part: "obtaining customer satisfaction"  "post-project review"
           "project staff re-allocation";

   part: "keeping the system running as intended"  "correct/prevent faults"
         "adding new and/or improved functions"  "adapt to changing environment"
         "improve function or performance" "help users"  "documenting! "
         "never losing sight of the meaning of 'System'" 
   method: "change requests" "approve or reject changes"  "re-cycle through SDLC"
           "plan, analyze, design, implement"
           "this requires configuration management",
   characteristic: "the most expensive component of system life cycle cost
                    (Pressman suggests 70-80% of system lifecycle cost!)",
   annotation: "good analysis and design and documentation is paid for many times 
                over by subsequent reduction in maintenance costs"
               "currently more programmers involved in maintenance than development!"
               "current and future trend: decrease in on-site maintenance";

     part: "keeping current system documentation up to date (part of configuration
            management and control)"   "planning ahead, and capture new requirements"
           "ensures only authorized changes are made to a system"
           "tracks state of current changes"  "traces history of changes"
           "authorizes programmers to have modification rights to certain modules",
     annotation: "system librarian oversees 'check-ins / outs'"
                 "some case tools have their own library control systems e.g. Cool-Gen";

   part: "control access"  "backup and recovery - data and software",
   characteristic: "highly valuable for corporate information and corporate information systems";

Alternative Tasks for Information System Development (Week 13)

 definition: "normally used for referring to approaches which use the 'prototype' as the
              final operational system"
             "a collection of approaches, techniques and tools aimed at reduced
              development times, rather than a specific methodology",
 purpose: "rapid identification of business problem and development and deployment of solution"
          "close cooperation between developers and users"
          "availability of prototyping and development tools",
 advantage: "extensive end-user involvement, leading to better end-solutions"
            "powerful development and prototyping tools (e.g. CASE code generators, 4GLs),
             allowing short development cycles"  "can result in significant cost savings",
 drawback: "nothing can be cheap, quick and good (and RAD isn't always necessarily cheap
            anyway!)"  "the almost complete focus on what the user wants will reduce
            opportunities for BPR"  "often fails to address important system requirements 
            (e.g. standards, documentation, consistency, scalability, security,
             maintenance etc)"  "can be very difficult to process, manage and forecast";

 annotation: "approach has been likened to more like an onion (contrast to the waterfall
              SDLC model)"  "progressive layers of system detail, starting with external
              qualities of the system, and continuing through to how the system will
              function and how it will be built"
              "models objects, encapsulating both data and behaviour",
 method: is#UMLS  is#Use_Cases_method;

   annotation: "represent functional requirements, what the system should do"
               "the Use Case represents a specific way of using the system: usually as
                a sequence of related actions to achieve some outcome or goal",
   support: is#object-oriented_diagram;


 subtype: is#system_analysis_and_design_project_manager
          is#system_analysis_and_design_programmer   is#instructional_designer 

   requirement: "must understand the entire process of systems development, as well as the
                 specific methodologies of structured analysis and design"
                "must have a knowledge of the business domain"
                "must have analytical skills to identify how that business domain might
                 benefit from IS Development"
                "must have management skills - to manage the development of the IS"
                "must have technical IT/IS skills"
                "must have teamwork and interpersonal skills";

Data structures and Document Formats/Content

 subtype: is#interview  is#object-oriented_diagram  is#project_plan
          is#data_structure_for_project_plan  is#project_model  is#data_flow_diagram
          is#output_document_of_program_design  is#data_structure_for_program_design
          is#test_plan  is#documention_of_the_project_implementation;

  is#interview  //Week 5
   subtype: is#interview_with_open-ended_questions  is#interview_with_closed-ended_questions
            is#individual_interview  is#group_interview;

     annotation: "does not suggest answers; e.g. 'What do you consider are the best aspects
                  of the current system?' or 'What do you think the main features of the 
                  new system should be?'";

     annotation: "suggests YES/NO answers, or constrains respondees to YES/NO answers,
                  or constrains respondees to choose from (or rating) your suggestions"
                 "particular care needs to be taken with Closed questions to not
                  'pre-condition' the response'",
     example: "Is the current system good?" 
              "Which of the following features do you think the new system should have
               (then list the options)?"
              "Rate each of the following features on a scale of 1 (must have) to 5 
               (don't need) ...";

     annotation: "in general better than group interviews because not dominated by the
                  loudest voice, the strongest personality or the highest position,
                  but Harder to schedule and 'keep on track' and less 'efficient'"
                 "do not allow interaction and discussion between interviewees";

   subtype: is#object-oriented_class_diagram is#object-oriented_state_diagram

     annotation: "represents static structure of the OO model: the object classes
                  themselves and their relationships";

     definition: "dynamic models of how objects change over time";

     definition: "dynamic models of interaction between object";

  is#project_plan //Week 2
   use: "representation and scheduling" "'Work Breakdown', or activities, or tasks, ...",
   annotation: "some terms: Critical Path, Slack time, Completion times (earliest and
                latest expected), Estimated (completion) times - optimistic, realistic,
   subtype: is#baseline_project_plan,
   support: is#data_structure_for_project_plan;

     annotation: "addresses various elements of this phase in detail"
                 "formats vary between organisations, but a suggested structure is
                  Introduction, Description, Feasibility Assessment, Management Issues";

   subtype: is#Gantt_chart  is#PERT_chart;

     annotation: "task activities and durations, set against a timeline",
     use: "shows task chronological, not logical, sequence"
          "shows duration, set against a timeline, but not logical sequence";

     annotation: "task activities and their relationships" "reveals the 'critical path'",
     use: "shows logical sequence but does not visually represent durations/timelines";

   subtype: is#process_model  is#data_model  is#logic_and_timing_model;

    is#process_model   //Week 6
     support: is#data_flow_diagram;

       annotation: "most common form of Process Models"
                   "despite the name, DFDs have a process focus rather than a data focus"
                   "representation of all processes and all information stores, irrespective
                    of whether or not they are computerised",
       subtype: is#current_physical_DFD  is#current_logical_DFD
                is#new_physical_DFD  is#new_logical_DFD,
       part:  is#DFD_process__DFD_activity__DFD_function  is#DFD_data_store
              is#DFD_external_entity  is#DFD_data_flow  1 is#DFD_context,
       object of: is#CASE_tool;

    is#data_model   //Week 7
     subtype: is#logical_data_model,
     annotation: "describes the data that support the business processes"
                 "shows the entities/attributes corresponding to the data stores in DFDs"
                 "during Analysis, the data model presents the logical organisation of
                  data, without regard to how these data are stored, created or manipulated;
                  during Design, these data models are changed to reflect these details",
     part: is#data_model_entity  is#data_model_attribute  is#data_model_relationship
           is#attribute_of_data_model_element  is#data_model_triggering_operation;

       definition: "a meaningful business object or concept about which data is stored
                    e.g. a person, place, event or an object",
       annotation: "an Entity will have multiple instances or occurrences - e.g. for
                    the entity patient, instances might be John Smith and Jill Jones",
       subtype: is#associative_entity,
       attribute: is#data_model_attribute   1..* is#data_model_candidate_key;

        is#associative_entity__Gerund  definition: "relationship modelled as entity";

       definition: "some type of information about entities, e.g. patient last_name, 
                    patient telephone_number",
       subtype: is#data_model_candidate_key,
       attribute: is#data_model_attribute_domain,
       object of: is#data_model_triggering_operation;

         definition: "an attribute serving to uniquely identify an instance of an entity";

         definition: "data type or value that an attribute can assume (e.g. type, length,
                      format, range, uniqueness, allowable values, etc)";

         annotation: "a condition of a rule on an event such as for example 'insert'";

       definition: "association between entities, e.g.: patient 'schedules' appointment",
       attribute: is#data_model_relationship_degree  is#data_model_relationship_cardinality
       subtype: {is#data_model_unary_relationship is#data_model_binary_relationship 

         definition: "the (maximum) number of times an instance of one entity can be 
                      related to instances of another entity",
         example: "a patient should have one and only one medical_history (1:1)"
                  "a patient may schedule many appointments but a particular appointment 
                   is only scheduled by one patient (1:M)"
                  "diseases can have many symptoms but symptoms can be associated with
                   many diseases (M:M)";

         definition: "the minimum number of times an instance of one entity can be related
                      to instances of another entity, e.g. a person would only be entered 
                      as a patient when they made an appointment (thereby signifying a 
                      modality or minimum cardinality of one)";

    is#logic_and_timing_model //Week 8
     subtype: is#structured_English__pseudocode  is#decision_table  is#decision_tree;
       annotation: "this is a communication technique for Analysts and Users, while
                    pseudocode is a communication between Analysts and Programmers"
                   "must represent control features of structured programming:
	            sequence, conditional statements, repetition"  "no standard";

       definition: "a diagram of process logic" "a matrix representation of a logic decision",
       use: "used when the logic is complicated, and/or we need to ensure all case/outcomes
             are considered"  "specifying possible conditions and their resulting actions",
       subtype: is#nested_decision_table;

   subtype: is#structure_chart  is#module_or_program_specification,
   support: is#data_structure_for_program_design;

     definition: "detailed description of module" "enough detail so programmer can code",
     support: is#pseudocode  is#flow_chart,
     part: "module common and technical name" "analyst and programmer name"
           "date received and due" "some business area context"  "list of requirements"
           "details of each requirement"  "unit test procedures"
           "references to site technical standards";

   subtype: is#pseudocode__pseudo-code  is#flow_chart  is#structure_chart_structure;

     definition: "a graphical Representation of structure of code",
     part: "symbols for sequence, condition/decision, repetition/recursion",
     subtype: is#Nassi-Shneiderman_flowchart;

     definition: "hierarchical diagram displaying organization of an information system
                  (each box is a module)"
                 "each process on levelled DFD loosely corresponds to a module on a 
                  structure chart BUT, it is NOT NECCESSARILY a one to one correlation:
                  may need to add controlling modules, may split a process into more 
                  than one module",
      support of: is#structure_chart;

   subtype: is#master_test_plan;

   subtype: is#technical_documentation  is#user_documentation  is#training_documentation;

     subtype: is#internal_code_documentation  is#data_dictionary  is#module_library_index;

     subtype: is#user_manual  is#template  is#online_help_text;

     subtype: is#trainer_manual  is#course_note;


 subtype: is#automated_project_management_tool  is#CASE_tool;

   annotation: "provides representational forms (e.g. Gantt, PERT) and much more",
   object: is#project_plan;

   annotation: "can help data modeling by (i) including names, descriptions, definitions,
                business rules etc in CASE repository and (ii) providing diagramming tools, 
                with 'links' between diagrams and CASE repository";