Module 3.pdf

1 -The project’s size, complexity, importance, and other factors REQUIREMENTS ENGINEERING AND MOD...

1 -The project’s size, complexity, importance, and other factors REQUIREMENTS ENGINEERING AND MODELING will affect how much effort is spent on collecting requirements CATEGORIES OF REQUIREMENTS 1. Functional SOFTWARE REQUIREMENTS Requirements -The 1990 IEEE Standard Glossary of Software Engineering 2. Non-Functional Requirements -Technical Terminology defines a requirement as follows: 1. A condition or -Non-Technical 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 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 -Customers often find it difficult to clearly describe what they want the system to do, and when they do list the requirements, FUNCTIONAL VS NON-FUNCTIONAL the result tends to be an unprioritized set of conflicting REQUIREMENTS capabilities NON-FUNCTIONAL REQUIREMENTS (NFR) 1. Technical Non-Functional Requirements 2. Non-Technical Non-Functional Requirements SYSTEM ANALYSIS PHASE OVERVIEW TECHNICAL NFRs -The overall objective of the system analysis phase is to: 1. Understand the proposed project -includes software attributes such as scalability, reliability, availability, recoverability, maintainability, security, 2. Ensure that it will support business requirements usability, integrity and the like 3. Build a solid foundation for system development NON-TECHNICAL NFRs REQUIREMENTS MODELING -includes regulatory, government, standards, culture, politics -involves fact-finding to describe the current system and identification of the requirements for the new system -requirements for a new systems: OTHER CLASSIFICATION OF REQUIREMENTS 1. Normal Requirements 1. Outputs 2. Inputs 2. Expected Requirements 3. Process 4. Performance 5. Security 3. Exciting Requirements What’s the Problem? Software Design Lecture Module 3 4 SYSTEM ANALYSIS SKILLS -Agile Development Analytical Skills JOINT APPLICATION DEVELOPMENT (JAD) -a -identify the problem team-based technique that brings users into the development -get the key elements process as active participants -develop a solution -User Involvement Interpersonal Skills -communicate and work with the people involved TEAM -BASED TECHNIQUES -Joint Application Development (JAD) -Rapid Application Development (RAD)  Advantages -allows key users to participate effectively in the requirements modelling process -it can result in a more accurate statement of system requirements, better understanding of the main goals and a stronger commitment to the success of the new system JAD: PROS AND CONS Software Design Lecture Module 3 5 RAD PHASES AND ACTIVITIES Disadvantages -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 Advantages development time and expense by involving users in -systems can be developed more quickly with significant every phase of systems development cost savings -it can be an attractive alternative, however, if an RAD: PROS AND CONS 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 -frequent deliverables constantly validate the project and reduce risk AGILE DEVELOPMENT: SCRUM -in scrum meeting, team members meet daily for 5-15 Disadvantages minutes -the people involved are supposed to answer 3 -the overall project may be subject to significant change in important questions scope as user requirements continue to evolve during the -What have you completed since the last meeting? project -What do you plan to complete by the next meeting? -What are the impediments? How will you resolve MODELING TOOLS AND TECHNIQUES it? -modeling involves graphical methods and nontechnical language that represent the sustem at various stages of AGILE: PROS AND CONS development Advantages -to help them understand system requirements, analysts use but -very flexible and efficient in dealing with change -stresses not limited to the following team interaction and reflect a set of community-based values -functional decomposition diagrams (FDD)  -business process models (BPM) BUSINESS PROCESS MODELING (BPM) -data flow diagram (DFD) -graphically displays one or more business processes -is a -unified modeling language (UML) diagrams standard language often use by analysts during FUNCTIOANL DECOMPOSITION DIAGRAM requirement modeling (FDD) -a top-down representation of a function or process -the overall diagram is called pool -FDD is use to model business functions and show how -a swim lane represents the sub-processes of a business they are organized into lower-level processes process 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 2. System rejects card 3. System sends rejection message Precondition: Customer has selected at least one item and has proceed to checkout area Postcondition: Credit card information has been validated, Customer can continue with order Assumption: None Sequence Diagram 2. Inputs 5. Controls -shows the timing of interactions between objects as they occur 3. Processes SYSTEM REQUIREMENT CHECKLIST -a system requirement is a characteristic or feature that must FACT-FINDING be included in an information system to satisfy business -is the process of collecting information requirements and be acceptable to users -fact-finding questions: -additionally, it serve as a benchmarks to measure the -Who, What, Where, When, How, and Why? overall acceptability of the finished system Note: there is a difference between asking what is being done and what -system requirement fall into five general categories: could or should be done 1. Outputs 4. Performance Software Design Lecture Module 3 11  2. Establish objectives for the interview 1. Who? Who performs each of the procedures within the -Determine the general areas to be discussed, and then list the system? facts you want to gather 2. What? What is being done? -Try to get ideas, suggestions, and opinions during the 3. Where? Where are the operations being interview performed? 4. When? When is a procedure performed? 3. Develop interview questions 5. How? How is a procedure performed? -Create a standard list of interview questions to keep you on CURRENT SYSTEM PROPOSED SYSTEM tract and avoid unnecessary tangents -The interview should consist of several different kinds of Who does it? Why does Who should do it? questions: open-ended, close-ended, or questions with a range this person do it? of responses What is done? Why is What should be done? -Avoid leading questions it done? -Types of questions: open-ended, close-ended, range-of response Where is it done? Why is Where should it be done? it done here? 4. Prepare for the interview When is it done? Why is When should it be done? -Careful preparation is essential it done then? -Limit the interview to no more than one hour -Send a list of topics to an interviewee several days before the How is it done? Why is How should it be done? meeting it done this way? -If you have questions about documents, ask the interviewee to have samples available at the meeting INTERVIEW 5. Conduct the interview -is a planned meeting during which the analyst obtains -Develop a specific plan for the meeting information from another person -Introduce yourself, describe the project, and explain your interview objectives HOW TO CONDUCT AN INTERVIEW? -Listen carefully to the answers -Give the person enough time to think about the question until 1. Determine the people to interview. he gets the answer -Select the right people to interview and ask them the right -Summarize the session and seek a confirmation from the other questions person Software Design Lecture Module 3 12 previously solved by other sources that can be either human or documents 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 -an people about a wide range of topics 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 Software Design Lecture Module 3