REQUIREMENTS ENGINEERING

Phase 1 Individual Project Requirements Engineering David Haskins CS455-1201B-01 Professor Sandra Cirel De Laus Colorado Technical University Online March 5, 2012

REQUIREMENTS ENGINEERING

Requirements Engineering seeks to define the functionality of a new system at an early stage of software development. Key system architectural features must exist to provide this functionality (Christel & Kang, 1992). Complete, relevant, and accurate requirements are the foundation for the design of a system that will meet user needs. In this report the author describes the different ways attributes of the new system are elicited during the engineering process. An overview of the requirements engineering process is given to highlight developer/user communications, acknowledging the importance of management participation in promoting this communication. The skills a developer will need to successfully elicit requirements for a new system are listed. The intended outcome of requirements elicitation process is given. Preparations needed for the online banking Web application requirements kickoff meeting are presented. A Software Requirements Specification outline is provided at the end of the report. Stakeholder Communication and other Requirement Discovery Techniques There are many techniques that facilitate communication between developers and users during the process of requirements elicitation. Interviewing stakeholders is a popular approach to eliciting information from stakeholders. (Phillips, 2009). Stakeholders should be identified and documented early in the process. Relevant information includes their position within the company, the hardware and software they use, the information that flows through the individual, and the individuals output or contribution to the organization. What do they do? Who do they report to? This is part of the domain knowledge developers will learn during requirements engineering. Topics of interest include business functions and processes that are related to the project. Interviews must be properly documented for the most benefit, and a recording and transcription technique can be effective. Structured interviews are good for soliciting unbiased,

REQUIREMENTS ENGINEERING

specific information including process descriptions. Unstructured interviews allow for less planning and the inclusion of feelings and opinions as well as ideas. A requirements workshop is a rapid fire technique that brings key stakeholders together to quickly define system requirements. The workshop is an effective way to refine the scope of a project, define requirements, elaborate on existing requirements, and prioritize requirements using consensus. Lasting one to three days, the success of the workshop depends on the skill of the facilitator and the knowledge of the participants. Brainstorming promotes creativity and can be used to attack a problem with as many ideas as possible. This technique fosters team work by getting the domain experts together and encouraging user participation. A whiteboard can be used to list ideas. A focus group also generates ideas. This one to two hour meeting also documents opinions and feelings of participants. The group can help define and analyze requirements or offer suggestions for improvement if the system is already in use. The diverse community offers multiple viewpoints. Stakeholder observation employs user shadowing techniques to watch an employee work, complete a process, or otherwise interact with an existing system. An analyst can observe a user passively and ask questions when the session is over or they can directly interact with the user by asking questions as they work through a process. The analyst must understand the reason behind each decision in order to understand the process. Surveys are an effective way to get feedback from large groups of users. Particular user groups can be targeted with precise questions. A well-prepared questionnaire could double check a process by using a walk-through using mockups, for example. Documenting users is useful for distributing surveys and other purposes.

REQUIREMENTS ENGINEERING Many times analysts must study information within an organization including

documentation and current processes and procedures. Working on existing systems requires problem-solving abilities and hands on experience. Document analysis is often used in system upgrades. It helps if the documentation clearly defines system operation and configuration. If the domain experts are no longer with the company the analyst will have to learn about the system using this documentation which includes business plans, marketing information, contracts, guidelines, standards, manuals, documentation from competing products, whitepapers, and other publications. The down side is this information may be difficult to locate, wrong, or incomplete. A prototype permits users to see and interact with an incomplete version of the system. They can walk though specific operations, adding insight for refinement or further requirements gathering. Developers display their understanding of the new system. Prototypes can be horizontal, providing a mockup with a wide view or vertical, where a single functionality is studied in depth. Evolutionary or working prototypes are created in increments and will become the final solution. Prototyping requires early communication and feedback. Communication during a Generic Requirements Engineering Methodology Inception begins when a need is realized for a solution to a problem, such as an inventory control system or an online store front Web site. A feasibility study is done and a software development company is approached with the problem (Mishra, & Mohanty, 2011). Developers must learn about the business problem and build upon their domain knowledge during the development of the software project. Stakeholders are identified and categorized by their viewpoints. Users can provide system objectives and can relate how the system supports the business on a daily basis.

REQUIREMENTS ENGINEERING

Requirements engineering is an iterative process that starts with requirements elicitation both at the beginning of the project and after each release, when functionalities are added or refined. Elicitation is the process of identifying user requirements. Fact-finding activities start with high level statements of the role of the new system and include organizational and domain analysis and a determination of whether similar systems exist. Problems encountered during elicitation include misunderstandings due to an undefined system scope and users that not understanding exactly what the software can do for them. All stakeholders that will be affected by the new system should be represented during elicitation, which lowers the risk of building a system that does not meet user requirements and builds a consensus of what characterizes a successful solution. Systems that are utilized within an organization will have users from various levels and departments of the company. The domain experts and users will provide the most input into the development of the application. Systems that face customer communities (Web sites) will have teams with members from marketing and other departments that will attend the stakeholder meetings. Hosting a requirements workshop is an effective way to kick off requirements elicitation. Developers can communicate with stakeholders before the requirements workshop either with interviews or by distributing handouts so that team members will be prepared for the meeting. Each stakeholder will be given a short tutorial on use cases and how each stakeholder views the system. The lesson can be simple, teaching users to show developers how they will use the system. When the meeting takes place each user will already have a tentative list of functionalities comprising their view of the system. The requirements workshops first topic of discussion is the justification for the new system. Members then submit their individual requirements lists which are combined on a whiteboard for

REQUIREMENTS ENGINEERING

all to see. Using brainstorming and other techniques, more requirements are added to the list. Attention is then focused on each requirement and group members add their input as constraints and performance criteria are negotiated. Rationale must be included with each requirement and to justify each decision point within a requirement. Members are separated into groups to work on the specifications for each requirement which will include validation criteria. Draft specifications created for the functionalities covered in the meeting are reviewed by those in attendance. An initial list of user requirements is the work product of elicitation activities. Included are statements of need, feasibility, and scope. Customers, users, and other stakeholders that participated in the elicitation process are documented. A technical description of the system comprises its capabilities, restraints, use case scenarios, domain models, and prototypes that were used to describe the system. The complexity of the system will dictate exactly which artifacts are required. The elaboration process is where initial requirements are expanded upon and refined. A technical model is created representing the systems functionalities and how the user will interact with the system. The analysis model is used to determine inputs, outputs, and processing behavior of the system, which have been validated by users. Requirements must be stated in a language that is understood by both users and developers and should be complete, accounting for all user groups. At this point final functional requirements have been created and are ready to be negotiated, prioritized, and validated. Negotiation is the process where customers prioritize functions based on business need. The feasibility of the system is approved by developers, including usability requirements. Different viewpoints are reconciled during negotiation as important stakeholders hash out priorities.

REQUIREMENTS ENGINEERING

Managers may have different agendas-marketing may be excited about the various features that will attract customers, production is concerned about performance and reliability, and executives will be worried about development costs. Developers may need to negotiate between these forces before development can continue. Each requirement is analyzed for risk, including estimates of development work, cost, and time. Tradeoffs may be required to satisfy all stakeholders. Validation is accomplished through a technical review. Again, a team of developers and users will test requirements to ensure the proper input that undergoes processing will produce the desired output. Work processes are double checked to ensure accuracy. The output of the validation phase is a software requirements specification (SRS). This documentation will serve as a basis for development activities and describes functional and performance requirements of the system as well as any constraints imposed on it. Backwards traceability of requirements to their sources helps during change management. An example would be a feature that is implemented based on a standard. When the standard changes, the feature must be analyzed based on the new standard. Key stakeholders participate, creating a loop of activities from conceptual development to demonstration and validation, where corrective feedback may lead back to the start of the phase. Novel systems will require a great deal of effort in the fact-finding activities at the beginning of elicitation. Demands for user interaction will be high at this time. Revising a system might concentrate users less on fact-finding and more on prioritization and validation. The Skills a Developer Will Need to Successfully Elicit Requirements Factors within the domain context that will have an effect on the requirements engineering process include the management hierarchy and style and the domain and computer experience of users (Christel, & Kang, 1992). Members of user communities have different backgrounds and

REQUIREMENTS ENGINEERING

experience levels, adding to the challenge of communication and understanding. Domain models further clarify the problem by dividing the domain into manageable pieces. Use case models in combination with entity relationship models and diagrams that illustrate the flow of data through the system are useful. As the project progresses, more knowledge comes to light and stakeholders better grasp what is expected of them. Domain analyses techniques help determine a systems informational requirements, promoting a common understanding of the problem. Information can be gathered directly from users or acquired from existing systems. Text books, manuals, standards, whitepapers and other publications, existing systems, and domain experts are sources of information that can be used to build domain models. Experienced users will provide requirements themselves while normative analysis, or the use of a basic prototype that is iteratively modified to meet user needs, would be a more successful approach when dealing with inexperienced users. In well-understood problem domains information about context already exists in some form. Novel systems may be quite challenging to understand and require multiple passes through the elicitation phase in parallel with validation techniques to capture a complete set of requirements. Having the right stakeholders involved from the start and the early verification of requirements is the key to a project that can be finished with quality, on time, at the right cost and limits volatility or changing requirements. Group development techniques, interviews, questionnaires, observations, and simulations are some tools developers can use to gather requirements. Validation ensures correct functionality that aligns well with the overall objectives of the system. The requirements engineer has a wide range of tasks they must complete in a given day. Most revolve around problem analysis, documentation, and communication. To be able to elicit a

REQUIREMENTS ENGINEERING

complete set of system requirements an analyst must be able to organize, integrate, and assess large amounts of information (Phillips, 2009). Interviewing skills and the ability to facilitate meetings are useful. Analysts must be able to learn about new domains by observing and analyzing processes, workflow, and how software is used within an organization in order to solve domain problems. Identification and use of patterns for efficiently structuring work and being able to write and otherwise communicate information is important. Listening, conflict resolution skills and the ability to promote a team attitude are valuable traits. Time and resource management and planning abilities make for a well-rounded analyst. Self-confidence and assertiveness is necessary in day to day work relations and persuasiveness is a good trait to have while negotiating. Outcome of Requirements Elicitation Process The output of the requirements elicitation process is documentation that includes: Statements of need, feasibility, and scope A list of stakeholders involved in the process A description of the technical environment of the system (hardware, software) A list of user requirements and system restraints Sets of use case scenarios, entity relationship and class diagrams, and any other models and prototypes used to facilitate stakeholder communication The work products will vary depending on the complexity of the system but a complete set of system use cases can go a long way towards the development of the desired system. Preparations for the Online Banking Web Application Requirements Kickoff Meeting The project calls for the creation of online banking services in support of a local bricks and mortar bank. The purpose for the system is to give customers the convenience of accessing

REQUIREMENTS ENGINEERING

10

various accounts on line while saving the bank the resources necessary to deal with these customers at the physical location. The solution will be in the form of a Web site for the bank. Since many similar systems have already been successfully deployed, the work will focus on which existing tools should be used and the look and feel of the application. In preparation of the requirements kickoff meeting analysts can provide documentation that stakeholders can look over before the meeting. Included will be screen shots from the Web sites of the top three competitor banks. Sample use cases accompany each existing solution to familiarize stakeholders with the concept of use cases. The appropriate stakeholders will be solicited for the types of accounts that users will be allowed to access on line with all transactions allowed against such accounts. The transactions are a superset of the use cases that will eventually be implemented in the system. The focus of the meeting will be to narrow down the list of use cases to those appropriate for the system. Other concerns brought forward by domain experts will be addressed.

Requirements engineering bridges the communication gap between customers and developers during software development. Elicitation is the process of identifying the user the requirements of a new system. Fact-finding activities start with high level statements of the objectives of the new system and include organizational and domain analysis and a determination of whether similar systems exist. Elicitation helps document the system scope before it is developed. All stakeholders that will be affected by the new system should be represented during elicitation for the best chance of building a system that meets user requirements and to build a consensus of what characterizes a successful solution. In this report the author described the different ways attributes of the new system are elicited during the engineering process. An overview of the requirements engineering process was given to

REQUIREMENTS ENGINEERING

11

highlight developer/user communications, acknowledging the importance of management participation in promoting this communication. The skills a developer will need to successfully elicit requirements for a new system were listed. The intended outcome of requirements elicitation process was given. Preparations needed for the online banking Web application requirements kickoff meeting were presented. A Software Requirements Specification outline is provided at the end of the report before the references.

REQUIREMENTS ENGINEERING Software Requirement Specification

12

Introduction: It provides an overview of the system, the software being developed, and the document. 1.1. Purpose of software and name of system for which it is being developed 1.2. Scope of software project, its benefits, objectives, and goals (i.e. how the software is related to the business goals) 1.3. Types of audience for whom the document is intended (e.g. programmers, users etc.) 1.4. Brief summary about the content of SRS and how it is organized Overall Description: High-level (summary) description of the software and its features are given in this section. 2.1. Product Perspective: 2.1.1. Context and origin of the software, about how it is initiated 2.1.2. A simple block diagram of the overall system to which the software relates 2.2. Product Features: 2.2.1. Major features and significant functions that the software performs 2.2.2. Organization of different functions/modules of the software 2.3. Category/types of users who will use the software 2.4. Performance Requirements 2.5. Operating Environment: Minimum and recommended system requirements for running the software such as hardware platform, operating system, database system, other mandatory and optional software components etc.

REQUIREMENTS ENGINEERING

13

2.6. Design and Implementation Constraints: List the items or issues to be taken care of in development of the software. These might include the organization's policies, government regulations, hardware limitations, compatibility to other applications, language requirements etc. 2.7. Security, safety, and privacy requirements 2.8. User Documentation: Specify the requirements of user manuals, on-line help that will be delivered along with the software. Specify if any design document and source code are also to be delivered. 2.9. Assumptions: List of assumed factors that could affect software requirements. Software Features: Detailed software features are described in this section. For each software feature: 3.1. State the name of the feature (in few words) 3.2. Describe the feature and its priority 3.3. Sequence the user actions and system responses 3.4. Functional requirements: Itemize detailed functional requirements associated with each feature. Each requirement may be numbered for unique identification. It is a standard practice to use various types of specification tools, charts, diagrams, and graphs for describing the specification. External Interface Requirements: Detailed description of different interfaces with the users, hardware devices, communication devices, and other software components are given here. 4.1 User Interfaces: Description of each input screen and their standard buttons and functions 4.2 Hardware Interfaces: Supported hardware devices and communication protocols 4.3 Software Interfaces:

REQUIREMENTS ENGINEERING

14

4.3.1. Connections with other software components including databases, operating systems, tools, and libraries 4.3.2. Data that will be shared across software components 4.4 Communication Interfaces 4.4.1. Requirements associated with any communication functions including e-mail, web browser, network server communications protocols, electronic forms, and so on 4.4.2. Requirements relating to communication security, data encryption, data transfer rates, and synchronization mechanisms Other Non-functional Requirements: 5.1. Performance Requirements 5.2. Safety and Security Requirements 5.2.1. Requirements relating to security or privacy 5.2.2. User identity authentication requirements 5.2.3. Statutory requirements due to any external policies or regulations 5.3. Software quality attributes such as adaptability, flexibility, interoperability, maintainability, portability, reliability, reusability, testability user-friendliness etc. 5.4. Other requirements not covered elsewhere in the SRS Appendix: 6.1. Glossary of terms 6.2. List of issues 6.3. Figures and diagrams

REQUIREMENTS ENGINEERING References Christel, M. & Kang, C. (1992). Issues in Requirements Elicitation. Retrieved from http://www.sei.cmu.edu/library/abstracts/reports/92tr012.cfm

15

Mishra, J. & Mohanty, A. (2011). Software Engineering. New Delhi, India: Pearson Education India. Retrieved from Safari Books Online at http://proquestcombo.safaribooksonline.com/9788131758694/ch003?readerfullscreen=&r eaderleftmenu=1&reader=html&imagepage Phillips, J. (2009). CBAP Certified Business Analysis Professional All-in-One Exam Guide. Columbus, OH: The McGraw-Hill Companies. Retrieved from Safari Books Online at http://proquestcombo.safaribooksonline.com/book/generalbusiness/9780071626699/elicitingrequirements/ch03lev1sec1?reader=html#X2ludGVybmFsX0ZsYXNoUmVhZGVyP3htb GlkPTk3ODAwNzE2MjY2OTkvY2gwMw== Pohl, K. & Rupp, C. (2011). Requirements Engineering Fundamentals. Santa Barbara, CA: Rocky Nook, Inc. Retrieved from Safari Books Online at http://proquestcombo.safaribooksonline.com/book/engineering/9781933952819/elicitingrequirements/eliciting_requirements#X2ludGVybmFsX0ZsYXNoUmVhZGVyP3htbGlk PTk3ODE5MzM5NTI4MTkvY2hhcmFjdGVyaXN0aWNzX29mX2FfcmVxdWlyZW1lb nRzX2VuZ2luZQ==