Introduction:
System engineering is a complex process that involves requirements definition and analysis, design, coding, testing and implementation (Joe Marasco, 2006).The quality of a system depends on the methodology adopted and the development activities. User requirements are the key to a successful product development. Requirements gathering and specification are accomplished by the process of requirements engineering which is a phase in system engineering. Prototyping is a technique which is widely used when the requirements are not clear. It is process of developing a rough replica of the proposed system so as to get a clear understanding of the requirements (Austin, 2007).
System requirements:
System engineering is a broad and complex software development process that applies scientific and engineering efforts in the transformation of user requirements into system specifications and co-ordination of system component development and their integration into a fully operational single system that solves user needs, and thus satisfies their requirements (Joe Marasco, 2006).
Software engineering has many phases starting from terms of reference, requirements analysis, system design, implementation (coding and resting), installation, signing off project to maintenance and evolution. The process puts into consideration aspects of reliability, availability, system interfaces, safety, maintainability, robustness, learnability, productivity and also ergonomics. Software engineering has an executable clear and precise system engineering management plan (SEMP) which is executed in each of the system engineering phases. Each phase produces a deliverable that tries to solve the user problem within budget and schedules constraints.
SEMP is a system level report defining the development activities and providing a description of overall project plan and the processes and deliverables needed in relation to meeting and satisfying user requirements.
Problem definition entails requirements gathering and analysis and is covered by requirements engineering process which is the first phase of system engineering.
Requirements engineering is a phase in system development that entails all the activities of user requirements identification, analysis of the so collected requirements to identify more requirements, converting the requirements into software systems requirements specification document (SRS document) and then validating and verifying the SRS document in relation to the user needs. Requirements engineering also encompasses the processes that ensure these activities are achieved and a deliverable is produced.
On technical basis, requirements engineering is the task of capturing, organizing and presenting the users needs so that they are implemented in a system that provides solution to the needs.
Requirements are of two types: user requirements and system requirements (also called functional requirements).
User requirements:
These are statements in simple natural language of users needs from the user perspective and in terminologies best understood by the user. They describe tasks the user will be able to perform with the system. (Jason Charvat, 2003)
System requirements:
These are detailed descriptions in technical terms of what the proposed system will do. They also describe the behavior of the system or a property or an attribute of the system.
How do we ensure that what we built is “fit for the purpose?”
Failure to analyze, organize and comprehend requirements will bring a system that is unacceptable by the customer. The developer may produce a system that is working properly and is of high quality in that context but if it does not reflect the system that the users wanted or need, then it is useless and in the users context is of poor quality.
Ensuring fitness for purpose is termed as developing a quality system that conforms to user requirements or needs and satisfies all stakeholders. The system development team must ensure the system conforms to the user needs or they deliver a system that satisfies the customer and the needs of all stakeholders. For example, Race cars development. When a customer is presented with cars like Mercedes, Jaguar and maclaren(F1), the customer whose needs are a race car will not choose Mercedes or jaguar because they don’t contain the right weight/power ratio, ground clearance and robustness properties , but the two cars are of high quality in the class of luxury but not racing. The best car would be the maclaren (F1) since it has those racing properties. (Elizabeth Hall, 2004).
Therefore, developers ensure that what they built is fit for purpose by a thorough and comprehensive requirements engineering process. This process will enable management to focus on delivery of a quality system.
Requirements engineering applies as the start of the system development lifecycle and in effect when proper requirements management is done then the development of a high quality system that is fit for purpose is inevitable. The developers need to spend relatively enough time on this stage so that they get all possible requirements (but usually don’t exhaust the requirements gathering), analyze and organize them so that the later stages can bring quality to the system.
In the process, the requirements specified have to be agreed upon by all affected stakeholders (including users, management, developers and organization) so that any conflict arising from the requirements can be resolved peacefully hence ensuring all stakeholders are satisfied before the next stage commences. This will ensure that the system developed satisfies the needs of all stakeholders and user requirements thus is “fit for the purpose” .
Validation needs to be done to check that the problem statement and user needs have been captured correctly and precisely. Such techniques in validation like reviews, inspection and structured analysis can be used by developers to check if the requirements are consistent, and structurally complete.
These techniques in requirements engineering will ensure that what is developed is fit for purpose and is of high quality.
How do developers progress when requirements are not clear?
Situations where requirements are unclear or are poorly understood arise due to complexity of problem at hand and also human complexity.
Problems that entail complex and large real world entities require solutions of complex and large systems. It is hard or difficult to know precisely the requirements of such systems.
Many times especially in an organization whose users don’t know much about computers, requirements provided by the users are often unclear, ambiguous, contradicting and also incomplete. Proceeding with system development when requirements are unclear would mean that developers would guess what the system is required to achieve and then start development. This will result in a situation where they will return later to the requirements engineering cycle and rework the software when they discover discrepancies. Therefore, developers need to develop and adapt a system development lifecycle methodology that will help to better capture and understand user requirements.
A good and mostly used methodology in development when needs are not clear is the prototyping approach.
Prototyping approach is combined with requirement management tools whose main focus is on requirement change management and requirement traceability.
Requirements management entails capturing requirements, organizing them and monitoring them throughout system development lifecycle (SDLC). Traceability techniques aim at linking artifacts from later stages against the original requirements. Such artifacts could be a business process (a use case) or a system functionality.
Progressing to development with unclear user requirements will definitely end in a rework process which decreases overall project productivity and may cause a project failure. In requirements management, requirements will be added, dropped or changed during the whole project lifecycle.
Prototyping is the development of a proposed system replica that can be easily modified and normally includes the proposed systems interface and the input/output (I/O) functionality.
Before the commencing on development it is fairly better to gather requirements explicitly, organize them and translate them into a system requirements specification document after validation. This way the product developed will be of good quality and acceptable by the customer.
Prototyping provides a visual representation of requirements and are of different kinds and may include painted screens, paper representations, animated screens or even programs. (Tharanian Mahendran, 2006).
The two main types of prototypes are:
Throw-away prototyping and
Evolutionary prototyping
Throw- away prototyping
This is prototype that is developed as a non-functional model of the proposed system so that developers can gather the user requirements in unclear situation and after the requirements are consistent and structurally complete, the prototype is discarded(hence the name ‘throw away’).( Acosta, R., et al.,1994) From there the system can be developed using other development methodology. The objective here is to derive and validate system requirements.
The developer starts with those known and poorly understood user requirements. After creation of the prototype it is presented to the user (in users working environment) so that they can make suggestions of improvements of structure/ features, additions or removal features. The views are then incorporated to the prototype. The iterative process continues until a final requirement agreement is reached at which level requirements are explicitly consistent and complete, then the prototype is thrown away.
The final prototype should not be used as the final system because: it does not model all the system characteristics and has no specification for long term maintenance because the system is poorly structured and hard to maintain. The prototype is normally undocumented. The advantage is that throw-away prototypes can be developed quickly and the method used is informal. The model is used by users to re-examine their needs and clarify their requirements. The model is thrown away after real requirements have been elicitated.
Evolutionary prototyping
This is an approach to prototyping where a fully working very robust and structured system prototype is initially produced and then refined through a number of phases of software development until it becomes the final system. The objective of this kind of prototyping is to produce and deliver a fully and correctly working system to the customer. The initial prototype forms the heart of the system and changes will be built on it.
The process starts with those requirements that are best known and understood which are used to develop the first working prototype. This working system is presented to the user by a qualified or skilled prototyper who acts in the place of the user, watches how users operate it and difficulties they encounter. Then takes these views together with those of the users, documents them as requests to be incorporated to the prototype during the next stage of development. This continues until the final system is delivered to the customer or end users. Evolutionary prototyping is used for systems where advance development of specifications is impracticable. Techniques used allow rapid system iterations. Since, there are no specifications then the verification of the system is not possible.
Advantages of Evolutionary prototyping approach are:
System development acceleration
Intensive user involvement –the system developed is more likely to meet user needs and satisfy all stakeholders involved. The intensive user involvement will help users to commit to the use of the system.
The phases of development are done at the same time (specification, design and implementation)
The prototypes developed at each stage are deliverables to the customer.
User interface is likely to be of high quality
Problems of Evolutionary prototyping
Most organizations standardized management processes tend to take waterfall model approach to system development.
The approach requires a highly skilled team of development that may be hard to get
The approach entails continued changes which iteratively damage system structure making it hard and expensive to maintain such a system.
Users may use the prototype on interim basis awaiting delivery of the refined system.
Another approach that developers can opt to proceed with when the requirements are unclear is the incremental approach to development (Aldaijy, A., 2004). In this approach, the proposed system is developed and delivered to customers in increments after establishment of overall system architecture.
The requirements and specifications are developed for each increment separately and users use these increments for experimentation while at the same time other increments are being developed. This way those known requirements can be used to start off the development and other requirements gathered afterwards for each increment during increment development. This approach combines same techniques and advantages of prototyping that ensures delivery of a system that conforms to user requirements.
Analyzing risk of going ahead
A risk is described as a possibility of loss. Many organizations opt to apply waterfall model of system development life cycle (SDLC) even when the requirements are not clear. Waterfall model is the most preferred and one of the best model practices. But this is true when requirements(both user and system requirements) are well known and understood, only this can enable developers to realize the quality fruits of using waterfall model as a development methodology.
Going head on with development with unclear requirements may yield good results in the essence of quite small and manageable projects but this is not true when it comes to large sized or complex systems.
Developing systems on unclear requirements impacts the system quality negatively. (Jason Charvat, 2003) These quality problems will result in requests for system change which inturn will have great negative impact on cost, schedule and the project scope.
Project scope is based on the requirements which determine how much work is needed in each phase of development. It is true that developing a project scope based on requirements that are not known well or are not clear is not practicable. This means that the project scope is subject to change during the project lifecycle. This change occurs due to changes to the requirements as development continues.
Furthermore, changes on the requirements occurring in later stages of development will lead to a rework and the development may made big progress. The rework process will go back to requirements engineering so that changes are reflected to the requirements document, then to every other succeeding phase.
Rework process has direct impacts to the project schedule and the total cost (budget) of the project. A lot of time is spend on rework not forgetting that remarkable time has already been spend until the time changes to requirements occur. Therefore, project schedule is prolonged and in many cases, such situations will cause a schedule to exceed of even more than 50% of the original schedule.
Increasing schedule has direct relation to budget. Reworking means costs will be incurred on the activities involved which means that the budget will overshoot the original by more than half since the rework process could mean new development.
In effect, project size or scope will change thus a project perceived to be small could change to be a huge and complex system development project. This complexity comes with it a new and different project plan. The new project plan would imply new budget and schedule constraints need to be established and optimized.
For example, users may decide that the requirements with which you have based development on are wrong and need to change (modified or removed) or new ones have to be implemented. The effect will not be as such as rework as it would be revision work on the product but a completely new system development starting from scratch.
This means that all what had been spend so far (in terms of budgetary and schedule constraints) was an overhaul that has brought no good results but loss to the organization. Rework in some cases could prove that the project is not viable and that the proposed changes are unrealistic in terms of current technology resources and the financial status of the organization. Such response from the development team would raise other issues of management that demoralizes the management and the development team. Such issues will bring the project to a stand still (i.e. if management decides to paralyze it for sometime) or even cause management to put off the project at the expense of another viable one. Therefore, rework can cause a project to be cancelled or discarded due to requirements inconsistence and incompleteness. The rework could also make budget and schedule to go beyond the expected (the budget and schedule may even double the original). The project scope is also hard to determine at first and thus could bring complexity issues at later stage (Agarwal, R., and B. Ghosh, 2000).
How we get user requirements and translate them to system engineering.
User requirements are the basic statements of what the users want to do with the system from the user’s point of view. To gather these requirements or needs, developers need to interact with users of the proposed system. The interactions are aimed at requirements gathering by use of questionnaires, interviews, observations, storyboarding, prototyping, workshops and even analysis of available documentation of current system or systems with the same domain.
The developer should explicitly help users figure out what they need in the system and requirements gathering techniques should be familiar, known and proven in the organization. This stage of requirements engineering is very important especially if developers need to help users determine their precise needs and enough time and effort should be spend here so as to almost exhaust user needs gathering.
System engineering is an iterative process that entails problem statement (problem definition), requirements gathering analysis, design, coding, testing, evaluation and validation, installation, maintenance and evolution. System engineering uses scientific and engineering applications to transform user requirements into system specification and co-ordinate development of system components and their integration into a whole system that solves user stated problem.
After the requirements gathering, acquired requirements are analyzed, organized, prioritized, validated and documented.
During analysis and organization, the basic user needs statements (which state what the system is needed to do by the user) are translated to system specification to achieve functional requirements of the system.
Functional requirements (also called system requirements) describe in detail what system is expected to perform, attributes and properties of the system together with the system behavior. The functional requirements which is documented in the system requirements specifications document (or it may be written in separate document) gives designers a good idea of how the system should perform what is required to do.
This in other terms means, user requirements describe what the system is needed to do while the translated functional requirements describe how to achieve the tasks of the users. The functional requirements (system specifications) are the ones that help translate user requirements into system design and code that implements those requirements.
Translation of user requirements into system engineering involve expanding in detail the user requirements and analyzing what is required from developers point of view and then writing how to achieve the stated user needs.
Requirement development and requirement process
Incorrect or unclear requirements definition and development coupled with inability to manage changes are base causes of project failure and possible rework.
Ensuring precise, accurate and complete requirements definition in the early stage of development (requirement engineering phase) and consequently managing the requirements and changes throughout the entire project lifecycle will help in reducing relative work or activities related to rework and also result in development of products of high quality and accurately conform to user needs. Therefore, the initial process of requirements development is very critical to the success of any software development project.
Requirements development process has five main critical areas that require intensive stakeholder involvement throughout the process. The critical areas are;
Elicitation
Analysis
Specification
Validation
Management
The process starts with the terms of reference which is the statement of the problem at hand and after a feasibility study has been conducted and recommends that the project is viable. After this an agreement should be arrived at among all stakeholders on the constraints of requirements definition process. The agreement establishes a schedule and role acceptance under the constraints of any organization standards, policies, domain technology, resource allocations, high level requirements and interfacing system schedules.
The organization and the project manager develop the acceptance criteria, cost and schedule plans for the development and see the initiation of the requirements elicitation process and effort.
This activity ensures a commitment of all stakeholders to the requirements and also establishes a plan of how the process is to be conducted. Precise requirements specification often play an important role in estimating project cost, schedule and technical feasibilities since the scope of the project is known.
Requirements elicitation
Elicitation is the first step of requirements process and it is closely related to other steps of the process. This so because requirements gathered at this step will have to be interpreted, analyzed, validated and managed so that the developer has confidence on completeness and accuracy of requirements collected. The needs of all stakeholders form the basis for identifying user requirements (Finkelstein, A., 1988).
Needs expectations, interfaces, product operational concepts and also constraints are gathered, analyzed, organized and prioritized, specified correctly and validated so that they can be transformed into the complete and accurate user requirements.
For in order to get precise requirements, iteration is used throughout the process of development lifecycle. Since all stakeholders cannot be involved, each class of stakeholders is represented by surrogates who help capture their needs and resolving any conflicts that arise.
This step of requirements process tries to find out what the system will solve thus establishing a system boundary which identifies where the proposed system will interface with the current technical and operational environment. These boundaries have to be identified and agreed upon because they are coupled with all elicitation efforts. And the boundaries will determine identification of stakeholders and their classes, use cases, goals and tasks of users.
Identifying stakeholders
Stakeholders of a system include customers, users (those who are to interact with the system to do their work), developers, and sponsors (also called client and they are the ones who pay for the project such as organization). All those who will gain or lose when the project is successful or fails are the stakeholders and they are very critical. In many systems (especially interactive systems) users are the key stakeholders who help in elicitation process (Antoniou, G., 1998). This is because usability attributes of a system are identified from the target user population.
Activities in this process of stakeholder identification are to identify different user classes and then proceed to determine their needs. Such user classes include novice users, expert users, administrator users and occasional users.
Objectives that the system must meet are the system goals. High level goals like those of business are continually transformed into low level goals which can be implemented via the system as system development continues. Requirements engineer or developer focus on problem and the stakeholders needs in relation to the problem domain (A.G. Sutclie, N.A.M. Maiden, December, 1993).
Users, in many occasions, can’t express what they want. Therefore the developer should focus on the tasks performed by the users or those tasks the users intend to perform with the system. This technique applies use of use cases that help visualize user requirements. The scenarios created by the developer using use cases bring a fair understanding of certain aspects of using the system.
Techniques used in elicitation:
Techniques chosen will largely depend on available resources and the time schedule. Techniques also depend on what is to be gathered. Techniques are categorized into classes:
Traditional techniques:
These techniques apply use of interviews, questionnaires, observations, surveys and analysis of existing documentation (for example, user manuals of existing systems with same domain, process models, business re-engineering documents or organization charts).
Group techniques:
Include consensus building groups, brainstorming, focus groups, and rapid application development (RAD) workshops. The objective is to reinforce stakeholder agreement at the same time establishing a richer understanding of needs through team abilities.
Prototyping technique:
This comes into full action when uncertainty on requirements exists or when requirements are unclear, (Tharanian Mahendran2006). It is also useful when an interactive system like Graphic User interface systems are being developed and intensive user Interaction is required. Prototyping (e.g. throw-away photo typing) can be used with other techniques like interviews, questionnaires, brainstorming or group workshops where a prototype can be used to provoke discussion areas & topics.
Model-driven techniques:
Includes goal- based and scenario-based methods. These methods provide specific models to the information being gathered. The model is used to drive elicitation process. Examples include data flow diagrams (DFD’s) and entity-relationship (E-R) diagrams.
Cognitive techniques:
These techniques were originally developed for knowledge-based systems for
acquisition of knowledge. The techniques include protocol analysis where expert think aloud while undertaking certain activity so that the observer (user) can get a fair understanding of the cognitive processes that arrive at the task’s final goal, laddering where searches/ queries to gather /capture structure & content of stake holder knowledge, card sorting where stakeholders are required to sort cards in groups with attribute matrix is created ( attributes &certain values are applicable to each entity provided by stake holders).
Contextual techniques:
Entails use of ethnographic techniques like participant observation, ethno methodology and conservation analysis- which apply fine grained analysis for pattern identification in interactions.
The most preferred requirements elicitation techniques are:
Interviews:
Interviews are used to elicitate information/data. The quality of data gotten depends wholly on the experience, understanding and the bias of the interviewee. Interviewer should use context-free questions to avoid prejudice responses from the interviewee.
Interviewer should base question on general terms and not centered to the person being interviewed. Preparation is necessary for a good start-read background document first. The developer should identify user groups & then the customer should proceed to select a representative from each group who should give requirements on the heart of the others (normally a representative of each group should have good knowledge & understanding of the discussion area).
Questions should be prepared in advance before the interview. This helps the interviewer to prepare well for the job. The same question should also be provided to the person to be interviewed in advance. Subjective decision-making business areas should be watched for.
Incase where users provide their needs as solutions, interviewer needs to ask the user what the solution given does. All information given by interviewee should be taken. If information being given by user is too broad, interviewer should request to recap on it later & note it down.
Visit electronic repository of indexed documents & meeting minutes before going for interview. This way the interviewer does not ask the same questions repeatedly. If facilities and resources allow, the developer should have two experts on the interview (one for asking the question & the other for noting answers down).Read through the notes while on the interview meeting so that the interviewee gives clarity & an okay. Developer should then assign team to resolve conflicting issues & obtain requirement prioritization from the users. Everyone in the meeting should be given notes from the meeting within few days. Give examples of technical attributes so that the interviewee can provide answers pertaining what technology they want.
Involve all stake holders (development team and users) in the requirement reviews to gain approval for implementation after the requirements are base lined. Approval for implementation should be determined by priority issues, cost & viability constraint.
Interviews should be conducted in the morning when the minds are fresh. Information gathered from an interview may include:
Ø What are the types of users and their skills?
Ø What are their roles & responsibilities?
Ø What problems they encounter while working?
Ø How tasks are performed, what are procedures for performing such tasks?
Ø What deliverable in results from the task is completed?
Ø What is the work environment?
Ø What are organizational goals & objectives supported by the task performed? Where are the resources gotten from?
Ø What are changes that occur on the task performance & how often do the
Changes occur?
Ø What information has been left by questions asked? And many more
questions.
Brainstorming:
This technique involves getting of ideas and also removal of ideas. The technique entails identifying as many ideas on requirements as possible and then ordering the ideas into most considered ideas by the group.(Byrne, J.G., Barlow, T., 1993). The group is comprised of different user group representatives and normally information generated in the meeting has diverse ideas. Most of these ideas are unusual but very prominent. This technique is powerful because it involves combinations of these unrelated ideas which result from very creative and effective thinking.
This technique involves team work and efforts usually prompt for the best knowledge of all team members (Byrne, J.G., Barlow, T., 1993). The technique can also be used in cases where requirements have been gathered but an understanding has not been obtained.
This way creativity and productivity is raised while at the same time gaining confidence from the customer for a good requirement elicitation process.
There are guidelines that can be used to make brainstorming sessions effective and more productive:
Ø Set objectives for the brainstorming session.
Ø Agree on the objectives.
Ø Equal treatment of members of the session.
Ø Base ideas on the objectives. Don’t focus outside the objectives.
Ø Each members view or ideas must be considered.
Ø Participation should be honest and sincere.
Ø Confidential aspects should be maintained as in an interview.
Ø Open mindedness is encouraged in the session.
Ø All questions are equal. There are no stupid questions.
Ø All misunderstood aspects should be discussed.
Ø Speak one person at time.
Ø All relevant ideas generated should be noted down
Ø A technique should be chosen collectively for purpose of prioritization.
Ø Incase of consensus, a voting method is chosen to resolve the issue.
Ø Be on time schedule-start & end time
Ø The session is subject for improvements.
Preferred methods of brainstorming include:
Each member has obligation of ranking the requirements from most important to least important- This is important in prioritization. Then each requirement is given a value according to the assigned importance and the total calculated for each requirement. The requirement with low value in given the 1st rank in the priority list (the highest priority requirements), the next low value requirements is ranked no. 2, & so on. This is the nominal group technique & it is appropriate where exact declinations of priorities are required.
Another method is having members (each) assign each requirements a medium, low or high designation which are converted to numerical values of medium = 2, high=3, and low =3. These values are used to develop a matrix that is quantifiable. All requirements are ranked according to their total values. This is a good method of prioritizing requirements.
Analyzing existing documentation:
Documents that can be analyzed are market research studies, contracts, proposal requests, working statements, guidelines & policies, existing systems documents, business procedures & business plans.
This involves examining the current documentation especially of existing systems to know & understand their requirements and then derive problems realized from those system documents which acts as requirements for the proposed system.
Documents of business procedures, guidelines & policies are studied carefully to determine business use cases for the proposed system. Work statements can be used to determine work processes and content, the work resources, users who do the work and environment. This information is then used to derive req. for the proposed system (T. K. Ho, J. J. Hull, S. N. Srihari,1991).
Existing system documents can also be used to help achieve clarity and competence, and understandability of proposed systems req.
Market research studies and business contracts can help to gather business requirements in the perspective of business marketing views and requirements. This technique coupled with other techniques will ensure the requirement Elicitation has covered all possible sources of requirements.
Document forms a major source of data regarding business processes. (T. K. Ho, J. J. Hull, S. N. Srihari, October 1991).
Documentation such as that of current system manuals and specifications document, organization stated objectives and goals, contractual document and organization work statements are usually large and information extraction is costly. If we consider the current system of which it is to be replaced, then extracting information from its document is a critical issue. The information extracted will be used to derive requirements of users and consequently analyzing, organizing and transforming them into the envisioned system functionalities, behavior, features and capabilities.
A technique used for document analysis is the probabilistic NLP (natural language processing) tools established at Lancaster in 1980s. These tools provide robust and accurate document information extraction. Probabilistic NLP provides abstraction to text in the document which users can use to identify certain meaning or need. Scaling of information is normally done and executive timing of such scaling depends largely on the size of the document.
After scaling, the users are able to interact with the document through use of retrieval and display tools. This way the user can select only the information they need to use from tagged text. Thus they don’t have to read the entire documents which can tiresome, time consuming tied with high costs. The information discovered in the document is used by the developers to derive real requirements of proposed system explicitly and accurately. But this is not a guarantee that all possible requirements can be gathered this way. The probabilistic NLP should be combined with other requirements gathering techniques so as to achieve maximum requirements productivity and hence ensure requirement gathering stage has been exhausted.
Workshops:
Workshops can be used in consensus establishment of requirements of particular
capabilities. Workshops are usually structured and facilitated events/sessions which are attended by group of stakeholders (who are carefully selected from each stakeholder group). The groups work together to identify, organize, verify and document set of predefined requirements for a proposed system and their expected deliverables.
Collaborative works are the most successful because the group works together to create product designs that will help achieve their common objectives. Collaboration means that their will be right mix of abilities and skills to derive and verify requirements The members work dependently using each others skills, abilities and knowledge views/ideas. Each is motivated to collaborate.
Workshops have no standard formula but are only made unique by the stakeholders, nature of project. Each participant in a collaborative workshop should be active, always busy, committed to the process and always focused to be performed in the workshop.
Best or preferred workshop guidelines are:
– Preparation methodology for workshop attendance is advisable.
– A checklist of activities of the workshop should be used.
– Organize and schedule the requirements Workshop.
– Standard requirements Questionnaires should be used to structure the meeting.
– Prepare workshop participants will, use effective communication methods like email broadcasting.
– Open mindedness should be used in questioning and also after session task lists should be established to attain meeting momentum.
– The environment should be protective and favorable to every participant.
– Contingency plans should be developed for the purpose of resolving unpleasant issues.
– Workshop evaluation should be used for process improvements.
– Workshop deliverables should be organized and analyzed.
– Maintain contact with all participants after workshop.
Workshops are used in elicitating requirements, analyze their details and uncover cross-functional implications which are unknown to individual stakeholders and they are often missed or defined incorrectly during user interviews. There are dedicated experts, whose job is to document the workshop discussion, ensuring that the developer concentrates on the requirements definition and workshop guidance.
JAD (Joint Application Development) workshop is a method where customer, users and developers collaborate through a facilitator to identify and derive requirement specifications that are agreeable to all. The workshop helps unearth user requirements early in development.
Storyboards:
These are sets of pager drawings that depict sets of activities performed by users in the current or proposed system. Developers or stakeholders start by drawing pictures of the properties and attributes they want the system to have. These features of the proposed system are evolved until desired requirements are precisely realized, organized, analyzed and an agreement achieved.
Story boards are like throw away paper prototypes but unlike prototypes storyboards are inexpensive and have low costs and also eliminate risks that are associated with prototyping.
Prototyping:
In this technique, a rough replica or model of the proposed system or parts of the system is created quickly and inexpensively. The process involves intensive user interactions because users are involved actively in requirements reviews and changes until real requirements are gathered (Walter Mauer, 1997).
The prototype serves as a communication and demonstration mechanism where users and stakeholders can determine their requirements and have a feel and look of the final system.(Tharanian Mahendran,2006). The prototype will also illustrate the structure and the desired capabilities of the proposed system.
Prototypes that can be used or developed for requirements gathering are,
· Exploratory or throw away prototypes
· Evolutionary prototypes
Throw away prototypes are built quickly with poorly understood requirements for demonstration and experimentation purposes. Usually they represent the structure of proposed system in correlation to the initial requirements. They don’t have any functionality. The prototype is then examined by the user to determine requirements. The prototype is refined by inclusion of emerging requirements and ideas until final real requirements have been confirmed and agreed upon. The prototype is then thrown away.
Evolutionary prototyping involves development of an initial working version of the proposed system using initial well understood needs. The prototype forms the heart of the final system. It is refined through a number of stages until the final system that satisfies user needs is delivered.
Prototypes are used in situations where requirements are unclear or the problem requires a complex and large solution and its needs are difficult to explicitly specify. It is also used intensively in design and development of interactive systems.
Use cases:
This is a methodology that is used in requirements development process to identify, clarify, specify and organize user and system requirements. (Ambler, S., 1995). Use cases consist of a combination of certain events and users performing them in specified environment using the system, regarding a final goal.
For example, user wants to prescribe medication to a patient using the system. The use case scenario includes all tasks or processes of a system which are prominent to the user in question. Use cases are represented a set of steps describing the user as the primary actor, what triggers the event and the system used to process the event. The steps arrive at a final predetermined goal.
The steps or use case can provide a description of how the user uses the system to arrive at the predetermined goal. In the essence of requirements definition, various scenarios can be derived from the use case that can provide viable alternative ways of achieving the goal.
Use cases usually provide descriptions of achieving a particular goal and the scenario generated involve interactions of an external actor and system that has been envisioned. The external actor defines the role of the person or object in the interaction. In one event or use case, the actor (if there is more than one role) can be represented as more than two actors in the interaction process.
A use case scenario is analogous to black box testing where the system is treated as a black box since the actor perceives reply or feedback data as to originate from outside the system. This is a good requirement abstraction from functionality issues. The developer is able to concentrate on what the system is required to do and not how to accomplish it.
Abstraction of the use case is categorized into two,
Business use cases
System use cases
Business use cases are defined or written in natural languages (no technical terms). The use cases provide descriptions of the business processes that are performed by business employees (actors) to achieve a specified goal. The business process value to the actor is defined and use cases provide the obligation of the process. These types of use cases are used to gather user information at the users understood languages and environment. This information is then used to derive user requirements.
System use cases Sub process. Descriptions which specify data input and predetermined data output. Provide description of the interaction of the user and the system in question. This implies that system use cases start with verbs. For example, delete file and update record.
An accurate and complete use case should be
Provide description of the support given to the user by the system in achieving a specified goal.
Use natural languages and not technical languages such as implementation language.
Provide all the details according to the use case level( whether at requirements gathering, system design or architectural design)
Have no user interface descriptions( in the requirements definition level)
Use case detail context levels
Brief use case-summarizes a use case with a couple of statements
Casual use case- summarizes a use case using a couple of paragraphs
Detailed use case- it is the formal use case documentation with detailed descriptions of all use cases and use case templates(with fields for various required date)
Complex and large projects use detailed use cases while relatively small projects can apply use cases with little information. In the initial stage of gathering business requirements statements from users point of view, simple use case (brief and casual use cases) are used while the detailed use cases are applied as development progresses further and more business process details are required (Karl E. Wiegers ,2003).
Use case templates
They provide structure and format for writing use cases and use cases scenarios. They are composed of fields and sections providing means of writing the information.
Typical sections of use case templates are (Cockburn, A., 2000);
Use case name. This is an identifier that is unique to a use case which is written in a verb-noun form. Since the use case is focused on users, it is appropriate to use actor’s final goal names.
Version. This indicates use case stage. A use case used in requirements elicitation should be different from the one that has evolved to reflect progressed system development like in design level
Summary. This introduces the content or importance of the use case before detailing the real use case. This can be used as an informant of what the use case implements, thus enabling people to read the parts they require. The information provided here defines the use case goal and the primary actors.
Preconditions. Describes conditions that have to be satisfied before a trigger causes the desired use case initiation.
Triggers. Provides description of the event that result to use case initiation. Events can include those from outside the system, those from inside or even temporal events. Trigger events initiates use case after receiving an okay from the trigger process which is set true when necessary conditions have been met
Basic course of vents. Each use case has to define the primary scenario which describes the path and steps to be followed in the use case process.
Alternative paths. This section defines various viable secondary courses of events which are different from the primary scenario. This Provides exceptions causing errors and which scenario to be followed after that.
Post conditions. Provides a description of the final system state after event completion.
Business rules. Describes business rules, regulations and policies with regard to a use case. Some business rules can apply to all or specific use cases.
Notes. This section is used by developers to write additional descriptions or materials regarding a use case incase template sections don’t provide enough space for description of a use case.
Author and date. Lists of use case creation and the person responsible for its documentation. Dates and versions of the use case are also listed here.
Use cases describe requirements in a more precise, clear form with regard to processes of the business. The use cases can be used for communication purposes where developers and stakeholders can agree and be satisfied by the completeness of the requirements and also the development progress.
Use case scenarios provide the developer with a good and precise understanding of the business needs which are understandable by the users. Alternatives of scenarios give a way of gathering information on most frequent system behavior hence increasing robustness and clarity of the system. Use cases are used together with other elicitation techniques and should never be used alone and expect to capture all possible requirements. Use cases provide team communication mechanism because they give a context of requirements by a description of events and scenarios in a language that is understandable to both users and the development team. (Ambler, S., 1995).
Modeling techniques:
Models are usually an abstraction representation to the real world situations and are used to facilitate understanding of the real problem and user requirements. The model abstracts certain properties attributes and behavior of a proposed system. The tool that is used in modeling is the CORE requirements tool that provides behavior encapsulation related to the real world proposed system. Modeling technique is used together with prototyping. The approach combination helps in requirements ambiguity and inconsistency elimination.
Data flow Diagrams (DFD’S):
Data flow diagrams show data flow within a system. It is a graphical representation of business process and accompanying transformation of data as it undergoes Input data- output data conditions with a system.
Decomposition
In the process of drawing DFD’S decomposition of DFD’S occurs which a process of system processes’ is modeling in increasing level of detail. This implies that the first DFD has fewer details than the next one and so forth.
Balancing
This is a caution exercised to ensure that all information in a DFD level is accurately presented in the next succeeding level. There needs to be an accurate & complete transition from one DFD level to the next ensuring that the data of the previous DFD level is fully presented in the current DFD level.
DFD’s can be of physical transactions or logical /conceptual business process DFD’s.
DFD’s are used for communication between users/stakeholders &among the development team through process modeling and also functional system requirements. Structured analysis in a tool for DFD’s that was developed in 1970’s. The tool can be used across different applications and usability platforms. Structured analysis in used together with data and workflow modeling tools and also textual specifications.
DFD tool is easy and simple to use by user and provides a decomposition of processes through continued specification refinement.
Steps of constructing a DFD
Develop context Diagram(level 0)
Establish DFD modules of each scenario.
Transform scenario fragments into context Diagrams(level 0)
Decompose the context Diagrams until refined.
Verity, validate and agree on the DFD’s with users.
Physical DFD models describe implementation details of processes while logical/conceptual DFD models describe a process without stating how they are implemented.
Process models represents (formally) business process operations while Data flow diagrams /DFD’s describes business process together with their accompanying data (data flows within the processes).
Data stores are the representation of how data moves & are transformed from one process condition to another (Blum, B. I., 1996).
External entities are the system boundaries & its outside environment.
Process shows data transformation. Data comes in a process as an input and is processed to produced a result (output)
Context diagram (Level O diagrams).
Show business context and the business processes as are simple process. They also Show external entities that receive or send in for to a system. The context diagram show processes making up a system and provides data stores.
Level1diagrams.
These entail all activities making up a single process in one diagram.
Data flow from one activity to another is displayed clearly and show in detail higher level contents. The diagrams may not be needed for all level 0 process.
Level 2 Diagrams.
Displays all processes making up a single process in one level 2 diagram and also how data flows to and from each comprising process. Each process is numbered for clarity and an understanding of how a process fits into the overall system. These diagrams may not be needed for all level 1 process.
Data flow splits & joins.
They show where data flow branches into components for different processes.
They are not necessarily mutually exclusive and all data from parent flow may not be used.
Data flow joins displays integration of components to form complex ones.
Alternative dataflow
They show different data produced by a single process under different processes.
DFD fragments.
Verb phrases are used for process names which are named with respect to organization point of view. Layouts of fragments places:
Processes at the outer.
Inputs from the left.
Outputs to the right.
Stores under the processes.
Example of level 0 fragment:
Customer
Sales representative
Customer Customer information
Information
Customer Report
A Second DFD fragment Example
A Second DFD fragment Example
Orders
Possible Orders
Customer Name
Customer
Customer Order
Cancel Order
Customer Available
D 2 Orders
D1 Customers
Information Orders Orders
Level 1and OTips.
Higher levels lists inputs & outputs sources.
Each DFD should list source destination of dataflows processes &data stores.
System complaity &size determines the depth of DFD.
Validating DFD’s.
Check for errors in syntax. The DFD structure should be correct
Check for semantic errors DFD accuracy should conform to expected business processes.
Walk throughs are agood technique of validating DFD’s(both structure and conformance to original business needs).
Names of all DFD’s should be accurate & correct check the decomposition aspects of lower levels to those of higher levels.
DFD diagrams combined with use cases are a sure way of gathering the user and functional requirements of the proposed system. However, the process requires a team with high skills & intelligence who perceive, identify and model business process while interacting with the user . The process sees requirements being devived from the DFD that show what the proposed system is expected to do. At the same time provides a good interface to the design phase since designers will use the DFD’s to derive & design how the system is to be organised.
Interface analysis:
This process is aimed at identifying user interfaces of system that will interact with the proposed system so that clarity is achieved on the project scope, be able to assess risks, help in project development cost reduction and get customer confidence. External system interface analysis entails identifying, simplifying, controlling, communicating and documenting interface problems. This technique eliminates interface risk problems.
Others requirement elicitation techniques (Ian Sommerville, 2000):
Other preferred elicitation techniques include performance and capacity analysis, data flow diagrams, transition process diagrams. Even with the application of the most preferred elicitation techniques, not all requirements are gathered. Requirements will keep on emerging and changes to the new ones will continue to happen. It is therefore not possible to exhaust elicitation of requirements and expect to develop the system from these requirements without any new or change issues in requirements arising along the project lifecycle.
Requirements case study1:
Requirements elicitation at Naval Strike and Air Warfare Centre (NSAWC)
Stakeholders
The key stake holders included NSAWC staff, various squadrons and the units being trained at the Fallon Training Range, U.S Navy, Army Air force and the Marines pilots(who were sing Fallon as a flying as well as a training place), Topgun, DynCorp(Development organization) and most importantly the schedulers who are the users of the system.
Problems:
The system that was used then was a paper work system that did not proof worthwhile and therefore the key users of the system wanted to automate the system. The problem was that those who were given the contract to do the automation failed and so users were very wary and serious with a last more try.
Those who had been given the contract before had failed because they did not understand the complexity and pressing issues that govern processes involved in the. The users were wary because pat attempts had wasted their time, failed to consider user acceptance as a critical issue and failed to understand the complexity of the processes involved (and to some extend tried to replace them instead of providing support for them).
Requirements elicitation process:
Andre Gous of PQS was the people who gathered on- site requirements and delivered them to DynCorp. In the process, Andre worked together with schedulers and spent couple of months in their offices. They were observing, and doing some actual work in the effort to gather requirements. They used extensive rapid prototyping to show the schedulers how the system will look like so as to get immediate feedback make improvements and derive new requirements through evolution process (Gomaa, H., I Thayer, R.H., Dorfman, M. ,1990. They also used visual tools to illustrate database implications under different conditions. To convey the requirements to DynCorp, Andre used Data modeling techniques to prove the need for a highly normalized database.
Outcome:
Users loved the system and the system went to operation under schedule and budget. All functionalities were fully operational and correct. The system was of high quality.
Lessons:
A thorough and comprehensive requirement engineering process dictates the quality attributes of a system, the budget and schedule constraints. Considerable time should be spent on the elicitation process so as to capture enough real user requirements. If requirements are not clear then methods of elicitation (Such as prototyping) that helps understand and define the unclear requirements need to be used. Intensive user-developer interaction is necessary to best define and understand user requirements.
Requirements case study2:
Requirements elicitation for Hp/Agile
Stakeholders:
The essence was to develop an employee safety and health training system to training employees on health and safety (EHS) courses.
Hewlett-Packard high voltage equipments which performed manufacturing, employees of the company whose health and safety was at stake, the employee , EHS administrator and the 3 bay area company locations.
Challenges:
The data was a lot and it was managed on central system. Managing this data was difficult. There was a need to : track employee supervisor and job description, indicate employee job description course of EHS to be taken, the course each employee had taken and the due date for each employee, track classes, enrollment and class performance for each employee, communication between the EHS administrator and other business managers and a need for report generation.
Requirements elicitation process:
The developers were the Andre Gous and Jamie Parker. They used interviewing technique to get a clear understanding of different users and their working environment.
Complex Data flow diagrams were used to model the data flows. Peer reviews were also used to validate and specify requirements. Data flows were also used to derive how conceptual components would evolve to database structures.
Outcome:
The users loved the safe- to- train EHS system and the administrator was congratulated by management for a good job. The system was a high quality product.
Lesson:
It is good to understand users and their working environment before starting to gather requirements. Interviewing technique is good for this purpose.
Data flow diagramming is very effective for describing and communicating data flows into a system.
Requirements modelling and Analysis.
This step commences once user requirements have been gathered .
Modeling is a fundamental activitity in requirements development process that entails construction of requirements abstract descriptions that are subject to amenable interpretation through validation and verification, (Al-Ani, B., 2003).
Modeling techniquies are also used in the elicitation step where the models help prompt for more requirements gathering (P. Coad, E. Yourdon, 1991).
Approaches of requirements modelling are:
Enterprise modelling
This kind of modelling entails an understanding of the structure of the organisation (rules governing organisations business operation goals and objectives of organisations, roles of organisation members and information needed, generated by and manipulated by the organisation). The technique derives the system purpose from organisation behavior description in which the system will operate. The behaviour is described in terms of business goals/objectives and the tasks resources used in business operation. A model can also describe anorganisation in respect to its rules and regulations, workflows and services provided. User and business requirements are refined through modeling that brings requirements that can be operationalised (Abadi, C., A. Bahill, 2002).
Data modeling:
Computer systems especially large information systems usually generate and use large amounts of information, which requires anunderstanding so that it can be manipulated and managed effectively.
Data modeling entails identifying data that is to be used by a proposed system and how that data conforms to real world problems that the system is trying to solve.
Entity – Retionship (E-R) model is used for data modeling andfanalysis but it is threatened by the currently increasing intensive use of object – oriented modeling that uses classes and objects and their hierarchies.(P. Coad E. Yourdon, 1991)
Behavioural modeling:
Involves modeling existing and desired functional behaviour of systems and stakeholders. The first step is to model how current system operates and analyse it to determine the essential functionality and develop models from the information to demonstrate how the proposed system must behave (Michael Jackson, 1995). The modeling methods provide different precitsion levels and are subject to different analysis approaches. Methods range from structured to object – oriented and from soft to formal methods.
Domain modeling:
Domain models provide abstraction description of the physical world the proposed system is required to operate (Acharya, S., et al., 2005). Explicit domain models permit a detailed thinking of what is perceived about domain and also provides requirements re-use advantage within a domain of same kind. (Finkelstein, A., 1988)
Non – Functional requirements modeling:
These are functions associated to quality( such as performance, learnability, and safety functions). These functions are difficult to analyse due to their difficult to measurement. They denote system properties and are therefore not related to individual modules.
Requirement models analysis:
Models are graphical representations and in consequence provide an easy way and opportunity of analysing them, “a picture speeks more than a thousand words.” Graphical representation of a system behaviour or property is easy to interprate and analyse since they are easily understood.
Analysis techniques include: requirements animation, automated reasoning(such as analogical and case – based reasoning), consistency checking(such as checking models), verification and validation techniques (such as reviews inspections and structured walkthroughs ).
Requirements specification:
Follows requirements analysis stage and it entails documenting the requirements in an unambigous, clear, precise and correct terms. Requirements are scoped so as to satisfy stakeholders vision. (Alan M. Davis,1992).
Specification also involves communicating the requirements to the different stakeholders. Document writing involves ensuring that they can be read, analyzed, rewriten (incases of changes) and validated easily and with ease. Different language notations have different expressions and reasoning to the stakeholders of the system (Al-Ani, B., 2003).
The deliverable of specification stage is a document called the System Requirements Specification(SRS) document that describes stakeholders needs and communicates them to the development team responsible for designing and coding the system. The document shouid be writen in a way that helps to communicate the it to all stakeholder groups.
Requirements are categorised into user and system requirements which are then documented seperately(Boehm, B., Bose, P., Horowitz, E. & Lee, M. J. ,1995).
Requirements specification document (SRS) serves as the contract between customer and development team. It gives description of functions of the system, performance and operation of the system, and constraints regarding user interface which determine system development.
SRS document serves as:
§ Contract between customer and development team
§ Starting point of system development
§ Addresses project lifecycle scope and project goals
§ Forms basis for quality assurance data formulation and test plans
§ Serves as adocument that helps manage rquirements
§ Means of evolving requirements during and after development
Requirements management:
This process ensures requirements analysis, verification and validation, and requirements traceability (Bennett K. H., Rajlich V. T., 2000). The process should ensure that requirements are described in precisely and unambiguously and that any omissions and errors are corrected early in development.
The management process ensures that changes in requirements during development lifecycle and even after signing off the project are correctly incorporated into the system requirements specification document and consequently in all other documents affected to reflect the changes(such other documents are design and code documents) through a good change management plan(Bennett K. H., Rajlich V. T., 2000).
Good requirements traceability technique should be established to ensure that it is easy to trace, read, navigate, query, and make changes to requirements document, (Wright, S., 1991).
Solutions;
Problems are seen in the requirements elicitation process (Alexander, I., 1998)
These problems include (Alexander, I., R. Stevens, 2002).
Process ambiguity and misunderstanding. The ambiguity is closely related to complex processes that entail many steps and events for in order to achieve a stated goal. This in effect makes it difficult for developers and users to understand all aspects of the processes.
Process inconsistency across multiple user platforms. This problem arises where a single process is understood and performed differently across a number of different stakeholders and users. This means deriving user requirements from such a process is hard and normally leads to conflicts among the different stakeholder groups.
Insufficient input from stakeholders. This is a problem that arises due to the fact that users normally don’t know how to express what they want. This means that the information they provide is insufficient may be incorrect to some extend, incomplete and maybe unrealistic. Stakeholders may say what they want to be implemented which in their view is achievable but on technological terms it cannot be achieved given the current organization technological status, budget and schedule constraints. In such situations, there is a big problem because user requirements can’t be identified well and therefore other techniques need to be applied so as to explicitly capture user requirements.
Conflicting stakeholder interests. A good quality system is one that satisfies user needs and is acceptable by all stakeholders. This means that all stakeholders’ needs must be captured and implemented. Usually a conflict will occur where different stakeholders hold different views on how the system should be or what the system should do. Such conflicts pose a threat to the success of the requirements engineering process and this translates to the success of entire project. A lot of time and effort is spend on the process of resolving these conflicting stakeholders interest. This is because the project should not proceed until this problem of interest conflict is resolved.
Changes in requirements in late phases of project lifecycle. Not all requirements are captured at the beginning. Technology is changing rapidly and in consequence new market trends emerge which brings about changes in user requirements. This means user requirements will continue to evolve once the project is signed off. In effect, the system proposed will need to incorporate all changes to requirements during development and after installation and signing off of project. The maintenance and evolution phase of software development lifecycle will have to work its miracles towards the evolution of the system to reflect ever changing user needs.
To solve these problems, the following practices of the requirements process must be applied:
Project scope and scope document should be written and iterated.
Provide means for effective communication between customer, users and the developers. This can be done through a project glossary with appropriate definitions to words that is acceptable and usable to the users and developers and also providing a list of acronyms.
Evolve requirements through interactive efforts of both users and developers. Product benefits is the main focus not system features. Prioritize requirements and address all of the requirements (both highest and minimum priority) requirements that are needed to satisfy stakeholders needs.
Document the purpose for each requirements (requirements rationale)
Train both requirements analysts and stakeholders representatives of each group. The training should address the following: Requirements analysts role-working with users to derive and evolve requirements, Ways of writing good requirements, Errors occurring in requirements and to solve those errors, Benefits of spending relatively valuable time on the requirements process, Project and organization requirement process, Overview of methods and techniques to be used in the requirements process, Using available automated requirement tools, and Using validation and verification (V & V) in requirement process.
Develop good change management mechanisms to help in controlling changes to requirements and evolved new ones. Prioritize requirements so as to determine these requirements to be implemented in the system version and those to be added continually.
If requirements are not clear or are poorly understood, apply incremental system development such as prototyping (throw away or evolutionary or both). This will ensure that users can get a feel and look and also use the system helping them to define and understand unclear requirements and also help in deriving new ones. This is true when a user is using the system.
Continually perform inspections and reviews of all requirements deliverables.
Requirements elicitation techniques used should be familiar, known and accepted in the organization (use preferred techniques such as prototyping, data flow diagram, workshops, analysis of existing documents or interviews.
Industry strength automated requirements tools should be used where: each requirement is assigned attributes, give traceability to each requirements and history of each requirements is managed.
Development team should consist of experts in the problem domain
Ensure an interactive involvement of users throughout the development process.
Apply requirement validation and verification in requirement elicitation process to ensure each requirement is operational and testable.
Adapt and standardize a continuous improvement quality culture of teamwork approach and ethnic continuity improvement.
Organization policies, processes, methods and techniques should be used to develop organizational and project approach evolvement group mechanisms that enable best practices of information sharing among project members.
Conclusion
Requirements engineering is process that is very critical to the success of an information system. Usually a system implements user needs which aims to satisfy a problem that exists so as to make it better. Many software development projects have failed to meet stakeholders needs due to failure to expliticitly define user requirements. Prototyping is used in situations where requirements are not clear or are poorly understood so as to get a clear understanding of users of the system and the system environment. This if achieved by use of either or both of the two approaches to prototyping which are throw- away and evolutionary prototyping. Throw-away prototypes are used to capture the real user requirements ant it is discarded. Evolutionary prototyping will be used as the final system after a series of prototype refinements (Kenji Takahashi, 1997).
If developers proceed with development when requirements are not clear, a re-work will result at a later stage of development due the changes in the requirements. This will cause increase in budget and the project to be delivered after the scheduled time.
The requirements process entails requirements elicitation, analysis, specification and management stages which are very critical. The best elicitation techniques include interviews, document analysis, workshops, and prototypes.
References
Jason Charvat (2003). Determine user requirements now to avoid problems later. Retrieved on 23rd September, 2007 from
http://articles.techrepublic.com/5100-22-5054103.html
Joe Marasco (2006). Unraveling the mystery of software development success. Retrieved on 23rd September, 2007 from
http://www.sandhill.com/opinion/editorial_print.php?id=67
Walter Mauer (1997). Prototyping. Retrieved on 23rd September, 2007 from
http://csweb.cs.bgsu.edu/mauer/domains/protol.htm
Tharanian Mahendran (2006). Significance of requirements prototyping. Retrieved on 23rd September, 2007 from
www.requirements.in/articles/20060//prototyping.html
Ian Sommerville (2000). Software engineering. 6th edition. Retrieved on 23rd September, 2007 from
www.comp.lancs.ac.uk/computing/resources/ians/SE6/slides/PPT/ch8.ppt.
Austin (2007). System development life cycle guide. Texas department of information resources. Retrieved on 23rd September, 2007 from
www.dir.state.state.tx.us/pubs/pfr/07-102/sdk-guide.pdf
Barry Boehm (January 1991). Software Risk Management- Principles and Practices, IEEE Software
Karl E. Wiegers (02/26/2003). Software Requirements, Second Edition.
Antoniou, G. (1998): The role of non monotonic representations in
requirements engineering. International Journal of Software
Engineering and Knowledge Engineering, 8(3): 385-399.
Bennett K. H., Rajlich V. T. (2000): Software Maintenance and
Evolution
Blum, B. I. (1996): Beyond Programming- To a New Era of Design.
Oxford, Oxford University Press.
Boehm, B. (1991): Software Risk Management- Principles and
Practices. IEEE Software, 8(1): 32-41.
Boehm, B., Bose, P., Horowitz, E. & Lee, M. J. (1995): Requirements Negotiation and Renegotiation Aids: A Theory-W based Spiral Approach. 17th International Conference on Software Engineering (ICSE-17), Seattle, USA,
Boehm, B. W. (1981): Software Engineering Economics. Englewood
Cliffs, NJ: Prentice-Hall.
Bohner, S. A. & Arnold, R. S. (Ed.). (1996): Software Change
Impact Analysis. IEEE Computer Society Press.
Elizabeth Hull (2004): Requirements engineering, Springer; 2nd edition- Processing
Natural Language Requirements. 12th International Conference on Automated Software
Engineering, Lake Tahoe, USA, 3-5 November 1997, pp. 36-45.
Bennett, K. H. & Rajlich, V. T. (2000): Software Maintenance and Evolution.
Blum, B. I. (1996): Beyond Programming: To a New Era of Design. Oxford, Oxford University Press.
Boehm, B. (1991): Software Risk Management: Principles and Practices. IEEE Software, 8(1): 32-41.
Bohner S. A. & Arnold R.S., (Ed.). (1996): Software Change Impact Analysis. IEEE Computer Society Press.
P. Coad, E. Yourdon (1991): Object Oriented Analysis. Yourdon Press
A. Dennis, G. Hayes, J. Nunamaker Jr.,J. Valacich(1991): Enterprise Ana-lyzer- Electronic Support for Group Requirements Elicitation(Technical report). University of Arizona
Alan M. Davis (1992): Software Requirements- Analysis and Specification. Prentice-Hall
Michael Jackson (1995): Software Requirement and Specifications. Addison-Wesley
A.G. Sutclie, N.A.M. Maiden (December 1993): Bridging the Requirements Gap: Policies, Goals and Domains Proceedings of the Seventh International Workshop on Software Specification and Design, Redondo Beach, California
Kenji Takahashi (1997): Hypermedia Support for Requirements Analysis. PhD thesis, Japan
Abadi, C., A. Bahill (2002): Separating Product and Process Requirements. International Symposium on Systems Engineering, Seattle, Washington: International Council on Systems Engineering
Acharya, S., et al. (2005): Domain consistency in requirements specification. Fifth International Conference on Quality Software, Los Alamitos, California. IEEE Computer Society Press
Acosta, R., et al.,(1994): A Case Study of Applying Rapid Prototyping Techniques in the Requirements Engineering Environment.IEEE International Conference on Requirements Engineering, Los Alamitos, California. IEEE Computer Society Press
Agarwal, R., and B. Ghosh, (2000): A Practical Approach for Iterative Re-Engineering of User Requirements. Sixth International Workshop on Requirements Engineering. Foundations for Software Quality, Stockholm, Sweden
Al-Ani, B., (2003): A Framework to Validate Requirements Engineering Research Artifacts. 1st International Workshop on Comparative Evaluation in Requirements Engineering, Sydney, Australia. Faculty of Information Technology, University of Technology, Sydney
Aldaijy, A.,(2004): Empirical Assessment of the Impact of Requirements Uncertainty on Development Quality Performance. Command and Control Research and Technology Symposium 2004, Command and Control Research Program, 2004.
Alexander, I., (15 October 1998): Why You Need Requirements Engineering. Requirements .Quarterly
Alexander, I., R. Stevens,(2002): Writing Better Requirements. London, UK: Addison-Wesley
Ambler, S. (1995): Using Use Cases: Reduce Development Costs with Use-Case Scenario Testing, Software Development
Cockburn, A. (2000): Writing Effective Use Cases. Addison-Wesley.
T. K. Ho, J. J. Hull, S. N. Srihari (October 1991): Word Recognition with Multi-Level Contextual Knowledge, Proc. of the 1st International Conference on Document Analysis and Recognition. St. Malo, France.
Byrne, J.G., Barlow, T. (1993): Structured brainstorming: A method for collecting user requirements. Human Factors and Ergonomics Society 37th Annual Meeting, pages 427-432.
Wright, S. (1991): Requirements traceability – what? why? And how? In Colloquium On Tools and Techniques For Maintaining Traceability During Design. The institution of electrical engineers.
Gomaa, H., I Thayer, R.H., Dorfman, M. (1990): The Impact of Prototyping on Software System Engineering- System and Software Requirements Engineering,
Finkelstein, A. (1988): Re-use of formatted requirements specifications. Software Engineering Journal, 3(5):186-197.
