Requirements Engineering and Modeling PDF

1 REQUIREMENTS ENGINEERING AND MODELING CATEGORIES OF REQUIREMENTS 1. Functional Requirements SOF...

1 REQUIREMENTS ENGINEERING AND MODELING CATEGORIES OF REQUIREMENTS 1. Functional Requirements SOFTWARE REQUIREMENTS 2. Non-Functional Requirements -The 1990 IEEE Standard Glossary of Software Engineering -Technical Terminology defines a requirement as follows: -Non-Technical 1. A condition or capability needed by a user to solve a problem or achieve an object 2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document 3. A documented representation of a condition or capability as in 1 or 2 REQUIREMENTS -a collection of items, or capabilities that the customer needs in the final deliverables REQUIREMENTS COLLECTION TECHNIQUES -How do you collect requirements? -Interviewing Stakeholders -Holding focus groups, facilitated workshops, etc. -Questionnaires and Surveys -Observation -Prototyping -The project’s size, complexity, importance, and other factors will affect how much effort is spent on collecting requirements Software Design Lecture Module 3  2 FUNCTIONAL REQUIREMENTS -are what you want the deliverable to do -describe the characteristics of the final deliverable in ordinary non-technical language -the important point to note is that WHAT is wanted to be specified and NOT HOW it will be delivered NON-FUNCTIONAL REQUIREMENTS -are product properties and focus on user expectations Software Design Lecture Module 3  3 FUNCTIONAL VS NON-FUNCTIONAL What’s the Problem? REQUIREMENTS -Customers often find it difficult to clearly describe what they want the system to do, and when they do list the requirements, the result tends to be an unprioritized set of conflicting capabilities NON-FUNCTIONAL REQUIREMENTS (NFR) 1. Technical Non-Functional Requirements 2. Non-Technical Non-Functional Requirements TECHNICAL NFRs -includes software attributes such as scalability, reliability, SYSTEM ANALYSIS PHASE OVERVIEW availability, recoverability, maintainability, security, usability, -The overall objective of the system analysis phase is to: integrity and the like 1. Understand the proposed project 2. Ensure that it will support business requirements NON-TECHNICAL NFRs 3. Build a solid foundation for system development -includes regulatory, government, standards, culture, politics REQUIREMENTS MODELING OTHER CLASSIFICATION OF REQUIREMENTS -involves fact-finding to describe the current system and 1. Normal Requirements identification of the requirements for the new system -requirements for a new systems: 2. Expected Requirements 1. Outputs 2. Inputs 3. Exciting Requirements 3. Process 4. Performance 5. Security Software Design Lecture Module 3  4 TEAM -BASED TECHNIQUES -Joint Application Development (JAD) -Rapid Application Development (RAD) -Agile Development JOINT APPLICATION DEVELOPMENT (JAD) -a team-based technique that brings users into the development process as active participants -User Involvement JAD: PROS AND CONS SYSTEM ANALYSIS SKILLS Advantages Analytical Skills -allows key users to participate effectively in the -identify the problem requirements modelling process -get the key elements -it can result in a more accurate statement of system -develop a solution requirements, better understanding of the main goals and a stronger commitment to the success of the new system Interpersonal Skills -communicate and work with the people involved Software Design Lecture Module 3  5 Disadvantages RAD PHASES AND ACTIVITIES -it can be expensive and be more complicated if the number of people involved for the said project is too large RAPID APPLICATION DEVELOPMENT (RAD) -is a team-based technique that speeds up -while the end product of JAD is a requirements model, the end product of RAD is the new information system -companies use RAD to reduce cost and development time and increase the probability of success -RAD relies heavily on prototyping and user involvement -RAD process allows users to examine a working model as early as possible, determine if it meets their needs, and suggest necessary changes. Based on user input, the prototype is modified RAD Objective -the main objective of all RAD approaches is to cut development time and expense by involving users in every phase of systems development RAD: PROS AND CONS Advantages -systems can be developed more quickly with significant cost savings -it can be an attractive alternative, however, if an organization understands the possible risks Software Design Lecture Module 3  6 Disadvantages -stresses the mechanics of the system itself and does not emphasize the company’s strategic business needs -accelerated time cycle might allow less time to develop quality, consistency, and design standards AGILE DEVELOPMENT -an agile approach emphasizes continuous feedback, and each incremental step is affected by what was learned in the prior steps. Thus, it attempts to develop a system incrementally -this approach, they believe, reinforces the agile strategy: simple, rapid, flexible, and user-oriented Software Design Lecture Module 3  7 AGILE DEVELOPMENT: SCRUM FUNCTIOANL DECOMPOSITION DIAGRAM (FDD) -in scrum meeting, team members meet daily for 5-15 minutes -a top-down representation of a function or process -the people involved are supposed to answer 3 important -FDD is use to model business functions and show how they questions are organized into lower-level processes -What have you completed since the last meeting? -What do you plan to complete by the next meeting? -What are the impediments? How will you resolve it? AGILE: PROS AND CONS Advantages -very flexible and efficient in dealing with change -stresses team interaction and reflect a set of community-based values -frequent deliverables constantly validate the project and reduce risk Disadvantages -the overall project may be subject to significant change in scope as user requirements continue to evolve during the project BUSINESS PROCESS MODELING (BPM) MODELING TOOLS AND TECHNIQUES -graphically displays one or more business processes -modeling involves graphical methods and nontechnical -is a standard language often use by analysts during language that represent the sustem at various stages of requirement modeling development -the overall diagram is called pool -to help them understand system requirements, analysts use but -a swim lane represents the sub-processes of a business not limited to the following process -functional decomposition diagrams (FDD) -business process models (BPM) -data flow diagram (DFD) -unified modeling language (UML) diagrams Software Design Lecture Module 3  8 DATA FLOW DIAGRAMS (DFD) -show how the system stores, processes, and transforms data through the use of various defined symbols like rectangles, circles, and arrows Software Design Lecture Module 3  9 Modeling Tools and Techniques USE CASE DIAGRAMS Unified Modeling Language -a widely used methods of visualizing and documenting software systems design Use Case Diagrams -visually represents the interaction between users and the information system -the user becomes an actor, with a specific role that describes how he or she interacts with the system Software Design Lecture Module 3  10 Name of Use Case: Credit card validation process Actor: Customer Description: Describes the credit card validation process Successful Completion: 1. Customer clicks the input selector and enters credit card number and expiration date 2. System verifies card 3. System sends authorization message Alternative: 1. Customer clicks the input selector and enters credit card number and expiration date SYSTEM REQUIREMENT CHECKLIST 2. System rejects card -a system requirement is a characteristic or feature that must 3. System sends rejection be included in an information system to satisfy business message requirements and be acceptable to users Precondition: Customer has selected at -additionally, it serve as a benchmarks to measure the least one item and has overall acceptability of the finished system proceed to checkout area -system requirement fall into five general categories: Postcondition: Credit card information has 1. Outputs 4. Performance been validated, 2. Inputs 5. Controls Customer can continue with order 3. Processes Assumption: None FACT-FINDING Sequence Diagram -is the process of collecting information -shows the timing of interactions between objects as they occur -fact-finding questions: -Who, What, Where, When, How, and Why? Note: there is a difference between asking what is being done and what could or should be done Software Design Lecture Module 3  11 1. Who? Who performs each of the procedures within the -Try to get ideas, suggestions, and opinions during the system? interview 2. What? What is being done? 3. Where? Where are the operations being performed? 3. Develop interview questions 4. When? When is a procedure performed? -Create a standard list of interview questions to keep you on 5. How? How is a procedure performed? tract and avoid unnecessary tangents -The interview should consist of several different kinds of CURRENT SYSTEM PROPOSED SYSTEM questions: open-ended, close-ended, or questions with a range Who does it? Why does this Who should do it? of responses person do it? -Avoid leading questions What is done? Why is it What should be done? -Types of questions: open-ended, close-ended, range-of- done? response Where is it done? Why is it Where should it be done? done here? 4. Prepare for the interview When is it done? Why is it When should it be done? -Careful preparation is essential done then? -Limit the interview to no more than one hour How is it done? Why is it How should it be done? -Send a list of topics to an interviewee several days before the done this way? meeting -If you have questions about documents, ask the interviewee to INTERVIEW have samples available at the meeting -is a planned meeting during which the analyst obtains information from another person 5. Conduct the interview -Develop a specific plan for the meeting HOW TO CONDUCT AN INTERVIEW? -Introduce yourself, describe the project, and explain your interview objectives 1. Determine the people to interview. -Listen carefully to the answers -Select the right people to interview and ask them the right -Give the person enough time to think about the question until questions he gets the answer -Summarize the session and seek a confirmation from the other 2. Establish objectives for the interview person -Determine the general areas to be discussed, and then list the facts you want to gather Software Design Lecture Module 3  12 6. Document the interview INTERVIEW VS QUESTIONNAIRES -Minimize note-taking during the interview -interview is a process of collecting information from -Record the information quickly individuals whereas questionnaires is a process of collecting -After the interview, appreciate the interviewee thru a memo information from large number of persons wherein the date, time, location, purpose, and the main points -interview is more flexible whereas questionnaire is less you discussed are noted so they can offer additions or flexible corrections -interview is less economical whereas Questionnaire is more economical 7. Evaluate the interview -Identify any possible biases -Interview takes a lot of time and money to conduct whereas -Unsuccessful interviews Questionnaire takes less time and money to conduct -Interview places more pressure on subject for immediate OTHER FACT-FINDING TECHNIQUES response whereas Questionnaire places less pressure 1. Document Review -Interview follows oral form whereas Questionnaire follows -How the current system is supposed to work written form 2. Observation -Interview nature is subjective, whereas Questionnaire nature -Gives you additional perspective and a better is objective understanding of system procedures 3. Questionnaires and Surveys DOCUMENTATION -Obtain input or information from a large number of -the basic rule on documentation is to write it down people about a wide range of topics -an analyst should document their work according to the 4. Sampling following principles: -Collect examples of actual documents -Record information as soon as it is obtained -Types of Sampling: -Use the simplest recording method possible -Systematic -Record findings in such a way that someone else can -Stratified understand them -Random -Organize documentation so related material is located 5. Research easily -The process of examining the problems which had previously solved by other sources that can be either human or documents Software Design Lecture Module 3