System Analysis

Anmerkungen:

• Definition: Analysis Phase: During this phase, the Business Analysis or Requirements Analysis is done. Sub-phases Business Analyst Fact fining techniques Feasibility Study Tools Used The systems analysis phase includes three activities: requirements modeling, data and process modeling, and consideration of development strategies

1. Analysis Phase
   1. Requirements Engineering

      Anmerkungen:

      • The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed.
      1. Types of Documentation
         1. SRS

            Anmerkungen:

            • Software Requirements Specifications: A detailed software description which can serve as a basis for a design or implementation. Written for developers.
            1. System Requirements

               Anmerkungen:

               • A structured document that goes more into detail of those specifications in User Requirements. Written as a contract between client and contractor. System Requirements may be expressed using system models.
               1. Req Validation

                  Anmerkungen:

                  • Concerned with demonstrating that the requirements defined in the system is what the customer really want. Requirements error costs are high so validation is very important  Fixing a requirements error after delivery is much higher
               2. Req Checking

                  Anmerkungen:

                  • Validity : Does the system provide the functions which best support the customer’s needs? Consistency : Are there any requirements conflicts?Completeness : Are all functions required by the customer included? Realism : Can the requirements be implemented given available budget and technology. Verifiability : Can the requirements be checked?
               3. Req Reviews

                  Anmerkungen:

                  • Both Users and developers should be involved in reviews. Regular reviews should be held while the requirements definition is being formulated. If possible include verification (testing) team at early stage of analysis
               4. Req Management

                  Anmerkungen:

                  • Requirements management is the process of managing changing requirements during the requirements engineering process and system development. Requirements are inevitably incomplete and inconsistent
               5. Req Change

                  Anmerkungen:

                  • The priority of requirements from different viewpoints changes during the development process. The business and technical environment of the system changes during its development. System customers may specify requirements from a business perspective that conflict with end-user requirements.
            2. Software Specifications

               Anmerkungen:

               • A detailed software description which can serve as a basis for a design or implementation. Written for developers.
         2. BRD

            Anmerkungen:

            • Business Requirements Document:
            1. User Requirements

               Anmerkungen:

               • Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers. Should describe functional and non-functional requirements.
               1. Feasibility Study
                  1. Technical Feasibility
                  2. Economical Feasibility
                  3. Operational Feasibility
               2. Guidelines for Writting User Requirements

                  Anmerkungen:

                  • Use a standard format for all requirements. Use language in a consistent way. Define mandatory requirements and desirable requirements clearly. Create a glossary of terms used. Avoid the use of computer jargon. Use Graphical depiction where possible.
      2. Requirement Determination

         Anmerkungen:

         • (output: BRD - Business Requirements Document)
         1. Business Analysis / Requirements Analysis
            1. Requirement Anticipation

               Anmerkungen:

               • Past Experience Define Scope Define Structure Prepare Questionnaire
            2. Requirement Investigation

               Anmerkungen:

               • Identify Requirement Requirement: “A statement of system service or constraint”. Use fact-finding techniques.
            3. Requirement Specification

               Anmerkungen:

               • A service statement, describing how the system would behave with user/system interaction. Expresses a restriction on the system’s behavior or on the system’s development. Tools to be used. Includes negotiations between developers and customers.
            4. Requirement Gathering

               Anmerkungen:

               • Determining what clients need from software.
               1. Fact-Finding Techniques

                  Anmerkungen:

                  • Who, What, Where, When, How, and Why?  Difference between asking what is being done and what could or should be done
                  1. Client's Direct Input
                     1. Interview

                        Anmerkungen:

                        • Interviews can be either: Structured Unstructured
                        1. 1 - Prepare

                           Anmerkungen:

                           • Careful preparation is essential because interview is an important meeting and not just a casual chat  Limit the interview to no more than one hour Send a list of topics Ask the interviewee to have samples available
                        2. 2 - Conduct

                           Anmerkungen:

                           • Develop a specific plan for the meeting. Begin by introducing yourself, describing the project, and explaining interview objectives. Use engaged listening. Allow the person enough time to think about the question. After interview, summarize the session and seek aconfirmation.
                        3. 3 - Document

                           Anmerkungen:

                           • Note taking should be kept to a minimum. After the interview, record the information quickly. After the interview, send memo expressing appreciation, including the main points discussed so the interviewee has a written summary and can offer additions or corrections.
                     2. Questionnaire / Surveys

                        Anmerkungen:

                        • Questionnaires / Surveys (Fill-in form) can be either: Open Response Close Response When designing a questionnaire, the most important rule of all is to make sure that your questions collect the right data in a form that you can use to further your fact-finding
                  2. Developer's Initiative
                     1. Observation
                     2. Site Visit
                     3. Research
      3. Requirement Analysis

         Anmerkungen:

         • Any system constraints (Output: SRS - Software Requirements Specifications)
         1. Classification of Requirements
            1. Functional Requirements

               Anmerkungen:

               • How the system should react to particular inputs. How the system should behave in particular situations. For example: Functional User requirements may be high-level statements of what the system should do.  Functional System requirements should describe the system services in detail.
               1. Requirements Principle

                  Anmerkungen:

                  • In practice, it is impossible to produce a complete and consistent requirements document.
                  1. Complete

                     Anmerkungen:

                     • They should include descriptions of all facilities required.
                  2. Consistent

                     Anmerkungen:

                     • There should be no conflicts or contradictions in the descriptions of the system facilities.
            2. Non-Functional Requirements

               Anmerkungen:

               • Constraints on the services or functions offered by the system (i.e. timing constraints, constraints on the development process, standards, etc.)

               Anlagen:

               • System Analysis - Non-Func Reqs
               1. Product

                  Anmerkungen:

                  • These requirements specify that the delivered product must behave in a particular way. (i.e. execution speed, reliability, etc.)
               2. Organisational

                  Anmerkungen:

                  • These requirements are a consequence of organisational policies and procedures (i.e. process standards used, implementation requirements, etc.)
               3. External

                  Anmerkungen:

                  • These requirements arise from factors which are external to the system and its development process (i.e. interoperability requirements, legislative requirements, etc.
            3. Domain Reqs?????