1. Systems Implementation and Support
1.1. Implementation activities
1.1.1. Program the software
1.1.2. Unit test the software
1.1.3. Identify and build test cases
1.1.4. Integrate and test components.
1.1.5. Usability test
1.1.6. System and stress test
1.2. Deployment activities
1.2.1. Data conversion
1.2.2. Training users
1.2.3. Configuring the production environment
1.2.4. Source code control system
1.2.5. Version control systems
1.2.6. Installation
1.2.6.1. Direct installation
1.2.6.2. Parallel installation
1.2.6.3. Phased installation
1.2.6.4. Pilot installation
1.2.7. maintenance
2. Systems Design
2.1. Design Environment
2.1.1. Network Specialists-based on strategic plan
2.2. Design and integrate network
2.3. Design Application Architecture & Software
2.3.1. Specify how use cases are carried out
2.3.2. Start with system architecture
2.3.3. move to detailed models
2.4. Design Databases
2.4.1. ERDs
2.4.2. Decide on structure
2.4.3. Security and Encryption
2.5. Design user Interface
2.5.1. Critical part of the system
2.5.2. user interface
2.5.3. HCI(human computer interaction)
2.5.3.1. Affordance
2.5.3.2. Consistency
2.5.3.3. Discoverability
2.5.3.4. Closure
2.5.3.5. Readability and Navigatiion
2.5.3.6. Usability and Efficiency
2.6. Design system Control
2.6.1. ensure that the system and data are secured and protected
2.6.2. need controls for
2.6.2.1. user interface
2.6.2.2. system interface
2.6.2.3. application architecture
2.6.2.4. database
2.6.2.5. network design
2.6.3. More information in control,Audit&Security unit
3. Alternatives for Implementation
3.1. Prioritise requirements
3.1.1. define the scope of the project precisely
3.2. Prioritising Requirements
3.2.1. Predictive approach
3.2.2. Adaptive approach
3.2.3. Determining the level of automation
3.2.3.1. Low
3.2.3.2. Medium
3.2.3.3. High
3.3. Alternatives
3.3.1. in-house
3.3.1.1. Satisfy unique business requirements
3.3.1.2. Minimise changes in business procedures and policies
3.3.1.3. Meet constraints of the existing system
3.3.1.4. Meet constraints of the existing technology
3.3.1.5. Develop internal resources and capabilities
3.3.2. out-source
3.3.2.1. Lower costs or to control the costs
3.3.2.2. Deal with rapid changes in software / hardware technology
3.3.2.3. Less time to implement
3.3.2.4. Proven reliability and performance benchmarks
3.3.2.5. Less technical development staff
3.3.2.6. Future upgrades provided by vendor
3.3.2.7. Obtain input from other companies
3.4. Selecting an alternative
3.4.1. General requirements
3.4.2. Technical requirements
3.4.3. Functional requirements
4. Analysing Requirements Entities
4.1. Modelling Requirements:Things
4.1.1. Brainstorming technique
4.1.1.1. Identify a user and a set of use cases.
4.1.1.2. Brainstorm with the user to identify things about which information should be captured by the system.
4.1.1.3. Use the types of things (categories) to systematically ask questions about potential things
4.1.1.4. Continue to work with all types of users and stakeholders to expand the brainstorming list
4.1.1.5. Merge the results, eliminate any duplicates, and compile an initial list.
4.1.2. Noun technique
4.1.2.1. Identify all nouns using the use cases, actors, and other information including inputs and outputs.
4.1.2.2. Use other information from existing systems including procedures, reports, forms, items or categories of information.
4.1.2.3. Refine the list of nouns.
4.1.2.4. Create a master list of all nouns identified and then note whether each one should be included, excluded, or researched further.
4.1.2.5. Review the list with users, stakeholders, and team members and then refine the list of things in the problem domain.
4.2. Characteristics of things
4.2.1. Attributes
4.2.1.1. Specific information about a thing
4.2.1.2. Identifier or key attributes
4.2.2. Relationship
4.2.2.1. Optional relationship
4.2.2.2. Mandatory relationship
4.2.2.3. Generalisation/specialisation relationship
4.2.2.4. Whole/part relationships
4.2.3. Domain Model Class Diagrams
4.2.3.1. Class
4.2.3.2. Class diagram
4.2.3.3. Domain model class diagram
4.2.3.4. camelback notation or camelCase notation
5. Development Approaches
5.1. Traditional Approach
5.1.1. Data Flow Diagram
5.1.1.1. Context Diagram
5.1.1.2. Expanding into sub-processes
5.1.1.3. Next level of DFDs
5.1.2. Data flow definitions
5.1.3. Process descriptions
5.1.4. Other traditional models
5.2. Object-Oriented Approach
5.2.1. Use case diagrams
5.2.2. Use case descriptions
5.2.3. System sequence diagrams
5.2.4. Activity diagrams
5.2.5. State machine diagrams
6. Modelling Approaches
6.1. Modelling Requirements
6.1.1. Use case descriptions and diagrams
6.1.2. Activity diagrams
6.1.3. Domain Model Class Diagrams / Entity Relationship Diagrams