System Analyst
November 1, 2007
Attributes of the system Analyst
The Analyst should possess various attributes, these are being a good communicator, in that he/she must act as a translator or a buffer between the technical staff and the users and management. He must be able to communicate effectively with these widely differing groups.
The Analyst should also be a good motivator, in that he/she must try to elicit cooperation from everyone involved in the project from the users to management and also the technical staff.
The Analyst should also be a good manager in that he/she should possess skills that enables him/her to coordinate the efforts of all those involved in the project, as well as be able to monitor and control the projects direction.
The Analyst must also be a business generalist in that he/she must maintain a broad business perspective at all times, he must know much about business as well as comp oriented issue.
The Analyst must also possess problem solving skills in that, he must be able to identify and determine the course of problems and find solutions and also be able to resolve conflicts.
The major human problems likely to be encountered by the analyst are:
The problem definition stage the analyst may encounter human problems such as a hesitant management in that the management may feel that the existing system is okay even if the user wants a new one.
In the feasibility stage, the analyst may encounter various problems such as organizational practices especially when the management wants to allocate major resources to the development of the information systems.
In design stage, the analyst may be faced with the problem of user resentment whereby the users keep changing their requirements and thus the project is delayed or it uses up all the resources.
In the construction phase, the Analyst may be faced with the problem of lack of skilled design team in that their level of competence may be low.
In the conversion or implementation phase the analyst may also be faced with the problem of incompetence of lack of skilled personnel in the organization or the planned users and operators of the system.
In the maintenance phase the analyst may be faced with the problem of user resentment in that the users might feel that they were cheated by the developers or even they may feel that the enhanced system may make them lose their jobs.
Factors contributing to difficulties in Maintenance
November 1, 2007
Limited user knowledge
The maintenance team deals with limitations of human understanding. Users understanding create a problem since they don’t have the skill or the understanding and thus it brings about unclear and incomplete problem report from them.
Thus the maintenance team needs to have good “people skills”. They must be able to know how different people think and work and they must be flexible in communication.
Management priorities
Management view maintenance activities as more important than the development of new application thus the maintenance team may be under pressure from the management to repair old systems even though users want new systems.
Problems of morale
Maintenance team of programmers is usually viewed as a second class status to development team of programmers thus affects their productivity
Programmer time
Programmers usually carry out various projects simultaneously thus demand on programmers time leads to conflicting priorities and thus unable to concentrate on one problem.
Problem of compromise
Some problems with the system may require a quick intelligent way of fixing problems usually this may not fit in with the design and coding style, thus this becomes a situation which requires a compromise either a quick fix or a procedural software engineering recommended way which will cost money and time.
Cost of maintenance
The cost may also bring in difficulties of maintaining a system.
Automated Maintenance tools
Text editors
It has the ability to copy a group of lines of codes from one place to another, thus saving the analyst from getting duplication errors and also saves his time of writing the codes again.
They have features which stores, the changes to one file in another separate file. This method is useful in making changes; they also provide a roll back facility to enable the earlier version to take place.
File comparison
This is a program that compares two files and reports differences between them. This program is used to ensure that a system or program that is supposed to be similar is as expected.
Compiler and linkage editors
These tools have features that simplify maintenance and configuration management. A compiler checks for syntax errors and for consistency across separately compiled components. When the code is compiled properly the linkage editor links the code with other modules required for running the program. Some linkage editors keep track of version numbers and ensure that the correct version numbers are linked together.
System Testing
November 1, 2007
TESTING
Verification and validation ensure that the program conforms to its specification and meet the needs of the software customer.
Verification ask the question “Are we building the product right?” It checks that the program conforms to its specification. Static techniques or static verification is concerned with the analysis and checking of system representation such as the requirements document, design diagrams and program source code.
Validation asks the question “Are we building the right product”. Validation involves checking that the program as implemented meets the expectations of the software customer. Requirements validation techniques such as prototyping help in this respect.
Static techniques used in verification include program inspections, analysis and formal verification. Static techniques can only check the correspondence between a program and its’ specification.
Alpha Testing is acceptance testing of bespoke software i.e. the customized software is taken to the clients who together with the developer agree that the final system is an acceptable implementation of the system requirements.
Beta testing happens when the software is in the open market for anyone to buy e.g. Microsoft products. Usually the developer takes it to a number of potential customers who agree to use the system and report any errors of defects to the developer. The system is then modified and suspected to further beta testing or for general sale.
Cluster testing is testing of group of classes in object oriented system which act in combination to provide a set of services.
TESTING
There are various ways of testing a system or modules, these are:
Incremental Testing
In this approach we test a module by itself and then immediately add on to it another module and test them. This process is carried out for each module. Incremental testing approach is in 3ways.
Top down incremental testing
We start with the president module and simulate the vice-president modules with dummy modules i.e. stub. Then we test the president, when we are sure the president works, we replace the dummy vice-president modules with real modules and we continue simulating the subordinates with stubs.
Bottom-Up Approach
Begins with the lowest modules and dummy modules (i.e. drivers or test harness) simulate the supervisor module and we thus test and replace the dummy modules with real modules after satisfying that they work properly.
Sandwich Testing Approach
This approach starts with one team at the top of the structure chart testing downwards while the other starts at the bottom going up.
Application of the Approaches
Top down approach tests the upper level interfaces repeatedly it is best used if upper level modules have complicated logic patterns and the bottom level i.e. input and output is straight forward.
Bottom up approach tests the lower level interfaces repeatedly it is best used if the lower level module of a complex database has serious problems where Input/Output
Test data
We should try to devise test data that will test every possible area and decisions, the loops, if and case constructs.
A normal path test employs data that are considered to be valid for the given decision. It should usually test areas in upper boundary, lower boundary and somewhere in between the boundaries.
An Exceptional test path Utilizes values that are not valid for a given decision, we test the upper, lower boundaries and invalid values.
The entire set of test data should be run every time a module is added to the system. Comparing the results of each successive test to make sure that the results have not been altered is called regression testing. Automated regression testers (ART) is a type of automated software tool that help us create test data, run tests and compare results.
System integration test: this test tries to express any defects that the system may have before handing it over to the user.
Acceptance testing: It establishes that all functions promised in the acceptance criteria of the problem specification have been delivered.
System implementation
October 30, 2007
Issues involved in system implementation
Testing is one aspect of system implementation, this involves various other issues. The programmers have to test the individual programs. This is called unit testing. It validates the internal code of a program. This may involve
-
Desk checking is a manual walkthrough of the program, checking code against the requirements specifications.
-
It is also concerned with checking that standards have been adhered to as well as identifying opportunities for syntactical and structural improvements.
-
Compiling: A clean compilation is required.
-
Test data: Test plans are prepared and the results compared with predicted test results. Test data should be manually compiled and the results produced by the system compared with appropriate clerical figures or the current computer system outputs.
-
Testing the interfaces between tested programmes: Each program should be tested with the programs with which it receives or passes data.
Integration testing should also be done; this is concerned with validating the operations of a suite of inter-connected programmes. It seeks to test that a logical subsystem is working correctly and that data is passed properly between parts of the subsystem.
System integration should also be done; it seeks to ensure that the sub-systems work properly together. This testing is performed against a specification and should pass through.
-
Single run i.e. testing a system over a single pass of test data.
-
Cyclic tests: i.e. involves testing a system over several cycles of processing thus ensures that it correctly deals with end of day, end of month and end of year routines.
-
Volume tests: This test tries to see how the system copes with agreed volume and possible overloads i.e. stress testing.
-
Clerical tests: This involves testing all aspects of the interface between the user and the system.
User acceptance testing is another kind of testing that is organized and performed by users. It is concerned with proving to their satisfaction, that the delivered system meets the specifications.
Testing is a time consuming activity and the automated aids to assist in production of test data should be encouraged e.g. data dictionary.
File conversion is another issue that arises in system implementation. This occurs in two levels i.e. if the current files are being held in a computer or they are manual.
If they are in computer, then it should be possible to move data to the target hub, but certain routines should be written such as stripping off control characters or transacting fields to modify the data format after conversion. The programmes carrying out this conversion have to be tested.
Data entry programs also have to be written for data that is to be collected for the first time. The designer may be able to use data input routines of the proposed system for entering current information into the computer.
A special file creation program has to be written and tested so as to capture old historical data that can’t be captured using the current programs.
Documentation is also another aspect of system implementation. This is a constant and continuous task in system development. The type of documentation that has to be produced is
-
Training documentation, this documentation will typically set objectives, explain concepts and commands to examine whether the objectives have been achieved. Such documentation may use conventional media and methods such as handouts, lectures or computer based training. This documentation is concerned with two principle tasks.
-
To ease the transition from the current system to its successor.
-
To provide detailed tuition in the operations of the proposed system.
-
-
User documentation. This materials concentrates on issues that concern the user most i.e. functional and errors, and information on how to get started. User manual should be a reference document and not a learning document. It should reflect the vocabulary and expertise of a variety of users involved in the system.
-
Operational documentation: this documentation describes the normal operating procedures of the system and how users can respond to errors.
Training is also another aspect of system implementation. It covers retraining of current staff and recruitment of new personnel. Retraining will require planning and coordination.
-
Setting objectives for training will suggest ways of delivering the training. It can be lectures; computer based training, on-job training e.t.c. Once the materials have been delivered, the attainment of the trainee and the effectiveness of the training methods can be assessed.
The final aspect of system implementation is the implementation strategies i.e. the changeover from the old to the new. These strategies are:
-
Parallel Changeover, in this method the old and the new system are run simultaneously for an agreed period of time and the two systems are compared. Parallel method causes large administrative overloads, although the method can be said to be “fail safe”. This method has another problem in that users tend to rely in existing procedures so problems of the new system are not discovered until the old system is phased out.
Direct Changeover, in this method the final cutoff date is set and when it reaches, the old system is done away with, the new one is implemented. In this method, there is roof “fail safe” system but it doesn’t cost much in cheaper than parallel.
Post Implementation Review
This phase provides the opportunity to review the conduct of the project i.e. achievements, failures, surprises and assessment, all these provide experience that can be used in the future developments. It is concerned with user satisfaction and also the way the project was conducted. The quality of the delivered system and its documentation and training can be monitored through:
-
Failure rates
-
Calls to Helpdesk
-
User satisfaction survey
-
Change request and the time taken to implement them.
-
Statistics concerning the use of the system.
-
At some stage, a review of the system will be done to ensure it conforms to the requirements set out at the feasibility stage and the costs have not exceeded those predicted.
-
There are bound to be some changes necessary and some data processing staff may be set aside for maintenance, which is aimed at ensuring continued efficient running of the system.
-
Some changes will be due to technological advances, changes in the organization or its environment or new user requirements or even correction of errors.
Criteria for evaluating the effectiveness of an implemented system
Efficiency of a system is not the same as effectiveness of the system. Effectiveness focuses on business goals. The methods or criteria for measuring effectiveness of a system are:
Customer satisfaction, this could be done through questionnaires or other survey methods. Customer satisfaction can be used especially in systems that were primarily designed for customers. This can be evidenced by retention of old customers and attracting new customers.
Staff morale (staff motivation analysis), this criteria can help us identify what has happened to users as a by product of implementation of the new system.
Cycle time, this takes into consideration the length of time that it takes to accomplish a task. Faster cycle time may mean that the system is well accepted.
Degree of use, this is used to evaluate the system, in that how many potential users or customers use the system.
Meeting the business objectives i.e. the degree to which the system actually supports the strategic business goals.
Structured techniques supported by CASE tools
October 30, 2007
Structured techniques supported by CASE tools.
Structured techniques are ways in which large and complex systems can be developed to be effective, usable, reliable and maintainable.
Traditionally systems which were developed concentrated on aspects of effectiveness, usability and reliability, thus the systems were hard to maintain. Thus structured techniques were developed to help make /develop systems which are easy to maintain.
A structured technique lays its foundation on the fact that:
-
A well designed system will need few corrections.
-
Its approach will help develop more reliable and maintainable systems.
-
The system characteristics should go hand in hand with the making systems easier to modify.
Structured techniques have the following principles.
In order to better manage the development process, large and complex systems should be broken down into phases and those phases, further broken down to smaller, more handled tasks.
We should use graphics to illustrate ideas whenever possible since graphics can often help or make it easier to understand. The commonly used graphics are:
-
Data Flow Diagram (DFD)
-
Entity Model (ERD)
-
Entity life Cycle (ELH)
We should always keep a written record of the project and tasks done. Documentation should be an integral part of SDLC rather than a follow up. Documentation helps outsiders, newcomers and employee/user of the organization to understand the system. It also helps in training the users.
We should use diagrams of the finished system plan to uncover errors before they are incorporated into the physical end product. In that a system still on paper is easier and cheaper to change than a final finished product, thus we should begin the validation process right from the feasibility study.
Case tools helps in making the structured techniques easy to implement. They help to automate the process of diagramming the function of the system.
Text editors also help in writing the documentation of the system.
Tools like test generators, comparators are used to make the testing process easy to handle.
Prototyping with 4GL(Generation Language)
Prototyping is the process of developing a working abbreviated version of the finished end product so as to enable the user to see what the finished product will look like.
4GLs are languages that help develop a system easily and quickly. A user only tells it what is to be done, and it writes and generates the code automatically.
Thus prototyping with 4GLs is the process of developing a prototype easily, quickly and cheaply. 4GLs can easily incorporate new user requirements and provide quick feedback when executed.
They enhance user involvement because user involvement is more or less continuous throughout the development process.
Addressing the following problems with a combination of structured techniques and prototyping
Problems of operational understanding
These problems may stem from the inability of users and management to comprehend the workings of the system. To solve this problem you would use either methods or ways.
You would need to break down the system operational process to small functional tasks which will be easier to explain and understand. In situations where the explanation is difficult you would use diagrams to explain your point e.g. using DFD to diagram a particular operational task.
You would also ensure in the documentation of the system you will not use jargons but simple English statements supported by diagrams.
Problems in fulfilling user requirements
This problem would either stem from unclear answers from users. To solve this problem I would use prototyping so as to gather user requirement as much as I can. I would adopt either a throwaway or evolutionary prototyping or I would work hand in hand with the users explain any of their questions and documenting their comments.
Structural techniques would also come in handy especially when gathering the requirements. I would diagram the functions of the new system and I would only adopt them in the documentation
REFERENCES
Modern Structured Analysis (Yourdon Press Computing Series)
Structured Systems Analysis: Tools and Techniques. (Prentice-Hall Software Series)
Practical Guide to Structured Systems Design (2nd Edition)
Managing the Structured Techniques (Yourdon Press Computing Series)
Introduction to Systems Analysis & Design: A Structured Approach
Practical Business Systems Development Using Ssadm: A Complete Tutorial Guide
Systems development methodology
October 30, 2007
A methodology can be described as a collection of procedures, techniques, tools and documentation aids which will help the system development. A methodology can thus be said to have various features. These features can be categorized into technical model and managerial model.
A methodology needs to have a technical model. This model includes features like the tools, processes and procedures. A methodology needs to have tools which will help the developers in the process of developing an Information System. These tools help in every phase or sub phase involved in the methodology e.g. CASE tools, project management tools, Drawing tools, Data dictionary e.t.c.
A methodology also needs to have a technique. Technique help to verify and expound on the methodology, thus they enable the phase and sub phase of methodology to be carried out according to the methodology’s principle. Technique acts as guides of methodology’s phase. Techniques address different parts (phases) of a methodology. A methodology can have many techniques. Techniques also enable easy understanding of what the methodology requires e.g. Decision trees/tables, Entity Life Cycle, Structured diagrams, normalization e.t.c.
A methodology also needs to have a philosophy, in that it needs to have the underlying theories and assumptions that the authors of the methodology believe in. This feature helps to shape and guide the development of an Information System. It also enables the understanding of the methodology.
A methodology also has a managerial model. This feature is that of the development structure, in that a methodology needs to have a development structure that;
-
Identifies the phases, sub phases, steps and tasks to be done in the methodology.
-
Identifies the outputs to be produced and under which circumstances they should be produced.
-
Constraints to be applied and people to be involved. This feature provides for the development process to be really managed and controlled.
The rationale for writing a methodology
A better end product: In that the methodology should improve the end product of a development process i.e. a better I.S.
A better development process: In that the methodology should provide improved management and project control so that the organization can gain from the benefits that accrue from a tightly controlled development process.
A standardized process in that people take up a methodology that can provide a common approach through out the organization so that they gain from the benefits of standardization mainly;
-
Better integration of projects or systems.
-
A base of common knowledge and experience is achieved.
Practical issues to be considered when selecting a methodology?
The practical issues are budget constraints; the organization should consider the cost associated with the methodology e.g. training, hardware, software costs, CASE tools, consultancy e.t.c.
Dependency on automated tools: in that the organization should look to see if the methodology depends on these tools and if the organization is happy with that or not.
Learning curve is another issue that the organization should consider.
Aids to future developments: if the methodology is feasible and can be adapted as technology changes.
Relevance to the application:
Human &Organizational factors leading to project failure
October 30, 2007
In traditional systems the technological failure was the major cause of failures in business data processing. Today, the failures are mainly caused by human and organizational problems.
Human problems are issues that are caused or raised by users and other people involved in the project that might cause the projects to fail. Some of these human problems are:
Lack of Co-operation in that the users may sabotage the project by not co-operating with the developers or some objectives that were not agreed upon by management may be introduced.
Poor training is also another human issue that may cause a project to fail. If the users are not properly trained on how to use the system, the project in turn will not be helpful as envisioned. Also the various people involved in the project may need to be sensitized on their roles e.g. sponsors, users e.t.c. so that they can know their responsibilities in the project.
Poor communication is also another human issue that can cause projects to fail. If the developers and the users of the system are not communicating then the project is doomed to fail. Proper channels of communication in a project must be clearly defined.
Lack of involvement of those needed in the project can cause it to fail, in that if the developers do not involve the users or the management in the project then chances are high that the project can fail.
Not all failures are caused by human factors; some failures are due to organizational factors like;
Lack of management support, the management may view the system or project as an issue for users and thus they may not get involved except when allocating resources, also projects need constant involvement by management and this may cause the manager to see it as a time wasting issue thus they may not get involved.
Lack of resources is another organizational issue that might cause projects to fail, in that the management may stop allocating some resources to the project midway. E.g. managers or money e.t.c. thus will cause the project to fail.
Lack of planning or poor planning may cause the project to fail in some way, in that the time, money allocated to the project might be so little for the project to work with hence it fails.
Lack of control in the project may cause the whole project to fail, in that the organization or the project manager may not put enough checks and review meetings to monitor and control the project.
External influences may also cause the project to fail in that factors such as social, political, economic, technical and legal issues may influence the project negatively and hence fail. Most projects often raise political and social issues and thus the management need to ensure that the project gets the political support needed and the local community support.
REFERENCES
Information Technology Project Management, Fourth Edition
Project Management: A Systems Approach to Planning, Scheduling, and Controlling
The Fast Forward MBA in Project Management, Second Edition
The Art of Project Management (Theory in Practice (O’Reilly))
Project Management: A Managerial Approach
Fundamentals of Technology Project Management
IT Project Management: On Track from Start to Finish, Second Edition (Certification Press)
Requirements analysis
October 30, 2007
Requirements Analysis (Elicitation)
After initial feasibility study, the first major stage of requirements engineering process is requirements analysis or elicitation. The technical software development staff works with users to find out
-
what functions the system should provide
-
required performance of the system
-
hardware constraints etc
This stage is depended on for user acceptance i.e. how well the system meets the users needs and supports the work to be automated.
Requirements Analysis is a difficult process because
-
Users often don’t really know what they want from the computer system.
-
Different users have different requirements and they express this in different ways.
-
Since analysis takes place in an organizational context, political factors in organizations may influence requirements of the system.
-
The economic and business environment in which analysis takes place is dynamic e.g. new requirements may emerge from users who were not originally consulted.
The process of gaining these requirements is iterative with continual feedback from each activity to other activities. The process activities are:
-
Domain understanding: Analysts must develop their understanding of the application domain e.g. If a system is for a supermarket, the Analyst finds out all he/she can about supermarkets.
-
Requirement collection: this is the process of interacting with users in the system to discover their requirements
-
Classification: This activity takes the unstructured collection of requirements and organizes them into coherent clusters.
-
Conflict Resolution: This involves finding and resolving conflicting requirements.
-
Privatization: This stage involves interaction with stakeholders to discover the most important requirements.
-
Requirements validation: The identified requirements are checked to discover if they are complete, consistent and in accordance with what you really want from the system.
Requirements Definition:
A system requirements definition is an abstract description of functions/services which the system should provide and the constraints under which the system must operate. It should only specify the external behaviour of the system it should not be concerned with system design characteristics.
The requirements should not be defined using an implementation model i.e. the definition should be written in such a way it’s understandable to users.
The requirements may either be functional or non functional
The functional requirements should be
-
Consistent: The requirements should not have contradictory definitions.
-
Complete: i.e. all functions required by the user should be defined.
Requirements specification:
This adds further information to the requirement definition. The requirements specification is usually presented with the system models developed during requirement Analysis.
The specification and the model should describe the system to be designed and implemented.
It should include all the necessary information about what the system must do and all the constraints on its operations.
Since the use of natural language on this document might bring problems e.g. misunderstanding because of ambiguity of natural language words, one can use alternatives such as
Structured natural language
This is a form of structured definition. It depends on using standard forms or templates to express the requirements specification
Design Description Language
This approach uses programming language but with more abstract features by defining an operational model of the system.
Requirements Specification Languages
These are special purpose languages that can be used to express software requirements such as PSL/PSA, RSL.
Graphical notations
This notations can be used for analysis and requirements specification eg SADT.
Mathematical specification:
These are mathematical formulas that are formal mathematical concepts such as finite state machines.
A requirement specification should have traceability i.e. the case of finding related requirement to achieve traceability one can:
-
have all requirements assigned unique number
-
Requirements should explicitly identify related requirements by referring to their number.
-
Each requirement document should contain a cross reference matrix showing related requirements.
Requirements Engineering
October 30, 2007
REQUIREMENTS ENGINEERING
Requirements engineering is the process of establishing what the new system should do. The requirements may be functional requirement or non functional requirement.
Functional requirement is one that describes the systems function or service while non functional requirement is a constraint placed on a system (e.g. Response time) or the development process.
These requirements can be said to evolve in 3 stages from requirements definition, to requirement specification and software specification.
-
Requirements Definition:
This is a high level abstract description of requirements. It can also be said to be a statement in natural language plus diagrams of what services the system is expected to provide and constraints under which it must operate.
-
Requirement specification:
This is a structured document which sets out the systems functions in detail i.e. detailed description of what the system should do.
-
Software specification
This is an abstract description of the software which is a basis for design and implementation. This is a document for the design team used for system development.
The requirements engineering process should normally involve writing a requirements definition then expanding this to requirements specification.
-
Different levels of system specification are useful because they communicate information about the system to different types of users.
-
Requirements information should be targeted to managerial level, it must be understandable by both client and contractor management who will not have a detailed technical knowledge of the system.
-
The requirement specification should be targeted at senior technical level staff and project managers.
-
Software specification is an implementation oriented document. It should be written for software engineers who will be involved in developing the system.
Requirements Engineering Process:
This process is the set of activities that lead to the production of the requirements definition and requirements specification. The 4 principle stages are:
-
Feasibility study:
This study should be relatively cheap and quick. It is an estimate of whether the identified user needs may be satisfied using current software and hardware technologies.
The study will decide whether the system (proposed system) will be cost effective from a business point of view and if it can be developed with the existing budgetary constraints.
The result of this study should form the decision of whether to go ahead with a more detailed analysis.
-
Requirements Analysis:
This is the process of deriving the system requirements through observation of existing systems, discussions with potential users and procurers, task analysis and so on.
It may involve development of system models to help the analyst understand the system to be specified.
-
Requirements definition:
This is the activity of translating the information gathered during the analysis activity into a document that defines a set of requirements. This should accurately reflect what the user wants. The document must be written so that it can be understood by end-user and system customer.
-
Requirements Specification:
A detailed and precise description of the system requirements is set out to act as a basis for a contract between client and the developer. During the development of the requirements specification, errors in requirements definition are discovered and they must be corrected.
The above activities are carried out in iteration i.e. the requirements analysis continues during definition and specification and new requirements arise during the process, thus the documents are suspect to frequent changes and should be placed under the control of a configuration management system.
Software Requirements Document:
This document is a combination of software definition and software specification. It is not a design document and it should set out what the system should do without specifying how it should be done.
-
The requirements should be stated so that there is traceability between these requirements and the final system design i.e. it should be possible to take each specified requirement and map it on to the part of the system design that implements that requirement.
-
The requirements set out on this document ought to be complete and consistent. All system functions should be specified and requirements should not conflict.
-
The document should be structured so that it can be easy to change: it should be split into chapters and sections.
-
Cross references from one requirement to another should be kept to a minimum.
Software requirement document should satisfy the following:
-
It should only specify external system behaviour
-
It should be easy to change
-
It should specify constraints on the implementation
-
It should record forethought about the lifecycle of the system.
-
It should characterize acceptable responses to undesired results.
The structure for a requirements document is
Introduction
-
should describe the need for the system briefly
-
its functions and how it will work with other systems briefly
-
it should describe how the system fits into the organization’s business or strategic objectives.
Functional Requirements:
Describe the functions the system is to achieve. The description should use diagrams, natural languages and other notations understandable by users.
Non Functional requirements:
It should define constraints imposed on the software and restrictions imposed on the designer should be described and related to functional requirements. It might include memory requirements, response time, and data representation.
System Models:
The document should set out one or more system models, showing the relationship between the system components and the system and its environment. This might include object models, dataflow models, and semantic data models.
System Evolution:
This should describe the fundamental assumptions on which the system is based and anticipated changes due to hardware evolution, changing user needs etc.
Requirements specification:
This should describe the functional requirements in more detail and also add more detail to non-functional requirements.
Glossary: This defines the technical terms used in the document.
Prototyping
October 25, 2007
Prototyping!
Prototype is the model of a business that serves as a model for future development.
A prototype of a business system may be used to demonstrate its initial performance and the system may be modified to achieve its objective.
A prototype may be used to
-
select the best design from a number of designs
-
to test a chosen design under different environmental conditions
-
To verify that the users needs have been met.
-
Verify that the design meets the specifications
Generally prototyping is not advisable for batch systems or one that produces standard hard copy report using a large institutional database. Online interactive systems favour prototyping e.g. advisable in decision support system.
There are 3 approaches to prototyping according to logical structured design methodology.
-
1st Approach:
In this approach a series of menus and screens are built and the user processes transaction as he would do in a live system. If it’s acceptable the prototype is further developed. This system is best when the user requirements are well defined and it does not support logic or a database.
-
2nd Approach:
This is building of a throw away version for user trials. It incorporates system logic in addition to menus screen and databases. This is the best used in large complex projects where user’s requirements are not well defined. The prototype software is unlikely to have performances and facilities for implementation as a physical system
-
3rd Approach
This is the second approach but the prototyping software is intended to form the final system. This becomes the pilot for a project with phased implementation plan.
Advantages of prototyping:
-
Enable the user to visualize how the system will work.
-
An accurate user requirement is met by or in that if one does not want a certain system or if it has a weakness one can change.
-
Increases productivity
-
Saves time and money on system analysis.
-
Improves or reduces backlogs by improving turn-around time in finding system solutions.
-
New user requirements can evolve
-
Increase productivity
-
Saves time and costs by ensuring they are implementing the correct design.
-
Heavy user involvement less resentment
-
Early training
-
User feel confident supporting a system they have already tested.
