System Analysis

System Analysis

1. Analysis Phase

   • Requirements Engineering
     • The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed.
     • Types of Documentation
       • SRS
         • Software Requirements Specifications: A detailed software description which can serve as a basis for a design or implementation. Written for developers.
         • System Requirements
           • 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.
           • Req Validation
             • 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
           • Req Checking
             • 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?
           • Req Reviews
             • 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
           • Req Management
             • Requirements management is the process of managing changing requirements during the requirements engineering process and system development. Requirements are inevitably incomplete and inconsistent
           • Req Change
             • 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.
         • Software Specifications
           • A detailed software description which can serve as a basis for a design or implementation. Written for developers.
       • BRD
         • Business Requirements Document:
         • User Requirements
           • 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.
           • Feasibility Study
             • Technical Feasibility
             • Economical Feasibility
             • Operational Feasibility
           • Guidelines for Writting User Requirements
             • 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.
     • Requirement Determination
       • (output: BRD - Business Requirements Document)
       • Business Analysis / Requirements Analysis
         • Requirement Anticipation
           • Past Experience Define Scope Define Structure Prepare Questionnaire
         • Requirement Investigation
           • Identify Requirement Requirement: “A statement of system service or constraint”. Use fact-finding techniques.
         • Requirement Specification
           • 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.
         • Requirement Gathering
           • Determining what clients need from software.
           • Fact-Finding Techniques
             • Who, What, Where, When, How, and Why?  Difference between asking what is being done and what could or should be done
             • Client's Direct Input
               • Interview
                 • Interviews can be either: Structured Unstructured
                 • 1 - Prepare
                   • 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 - Conduct
                   • 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 - Document
                   • 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.
               • Questionnaire / Surveys
                 • 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
             • Developer's Initiative
               • Observation
               • Site Visit
               • Research
     • Requirement Analysis
       • Any system constraints (Output: SRS - Software Requirements Specifications)
       • Classification of Requirements
         • Functional Requirements
           • 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.
           • Requirements Principle
             • In practice, it is impossible to produce a complete and consistent requirements document.
             • Complete
               • They should include descriptions of all facilities required.
             • Consistent
               • There should be no conflicts or contradictions in the descriptions of the system facilities.
         • Non-Functional Requirements
           • Constraints on the services or functions offered by the system (i.e. timing constraints, constraints on the development process, standards, etc.)
           • System Analysis - Non-Func Reqs
           • Product
             • These requirements specify that the delivered product must behave in a particular way. (i.e. execution speed, reliability, etc.)
           • Organisational
             • These requirements are a consequence of organisational policies and procedures (i.e. process standards used, implementation requirements, etc.)
           • External
             • These requirements arise from factors which are external to the system and its development process (i.e. interoperability requirements, legislative requirements, etc.
         • Domain Reqs?????