Software Requirements Requirements engineering Domain modeling - PDF document

Outline  Starting point Software Requirements  Requirements engineering  Domain modeling  Problem scoping / decomposition  Requirements types Eunjee Song  Functional / Non-functional Computer Science Department  FURPS+ Baylor University  Requirements models Eunjee Song Software Requirements - 1 Eunjee Song Software Requirements - 2 Starting Point Why are Requirements Important? http://www.cs.cornell.edu/courses/cs501/2006sp/slides/ Software Design Requirements Analysis Implementation Causes of failed software projects (Standish Group study, 1994) System Engineering Incomplete requirements 13.1% Testing Lack of user involvement 12.4% Deployment Lack of resources 10.6% Requirements Clients have produced Unrealistic expectations 9.9% Evolution must be determined requirements Lack of executive support 9.3% New A B Changing requirements & specifications 8.8% development Lack of planning 8.1% Evolution of C D System no longer needed 7.5% existing system The commonest mistake is to build the wrong system! Eunjee Song Eunjee Song Software Requirements - 3 Software Requirements - 4 Why are Requirements Important? Requirements Engineering?  The process of discovering, documenting and maintaining the tasks or functions the software should carry out. As Management requested it. As Management requested it. As the Project Leader defined it. As the Project Leader defined it. As Systems designed it. As Systems designed it.  The term “engineering” implies a systematic and repeatable process. As Programming developed it. As Operations installed it. What the user wanted. (Pre-1970 cartoon; origin unknown) Eunjee Song Eunjee Song Software Requirements - 5 Software Requirements - 6 1

Foundationsof requirements engineering Software Requirements Engineering Focus on eliciting, analyzing, documenting and managing  Cognitive psychology  requirements for the software component of a system.  What difficulties do people have describing their needs? Requirements Elicitation Analysis Specification Validation Management  Uncovering tacit knowledge of a domain expert Elicitation : extracting requirements from customers and users   Mental modeling Analysis : analyzing and organizing requirements to gain   Anthropology deeper understanding  A systematic approach to observing human behavior Results of analysis reflected in models  Specification : detailed documentation of required behavior  Sociology  Validation : requirements are validated against customer/user   Understanding political and cultural needs changes/challenges caused by computerization Requirements management : activities related to documenting,   Linguistics controlling and tracking requirements and changes to  Understanding how to communicate unambiguously requirements Eunjee Song Software Requirements - 7 Eunjee Song Software Requirements - 8 What is a software requirement? Understanding the Context of a Software Application 1 Whom is the application for?   A requirement is a statement about the proposed Identify stakeholders (customers, end-users)  software that all stakeholders agree must be What problems will it solve?  made true in order for the customer’s problem to Establish scope: determine features that will be in application and which  will not be adequately solved . Where will it be used?   Says something about what the software does and Determine whether application is mission-critical, experimental, or a  non-disruptive new capability, etc. non disruptive new capability etc what data it maintains Understand how the application will fit in with other systems   All the stakeholders have agreed that it is valid When is it needed?  Determine feasible time application can be developed and required time  It helps solve the customer’s problem  application is needed to meet business goals  A collection of requirements is a requirements Why is it needed?  Build a business case for the application document .  How will it work?  Brainstorm feasibility of solving the problem  Eunjee Song Eunjee Song Software Requirements - 9 Software Requirements - 10 Understanding the Context of a Software What is a Domain Model? Application 2  Structuring of domain concepts  Identifies problem concepts and their relationships  Domain analysis : the process by which a  UML structural model used to depict structure software engineer learns about the domain to better understand the problem:  Key Question: What are the objects of interest in  The domain is the general field of business or this domain? technology in which the clients will use the  their attributes? software software  their relationships?  A domain expert is a person who has a deep  IMPORTANT: This is a model of problem knowledge of the domain concepts ; these concepts are NOT software  A domain model is created to describe some objects, but a “visual dictionary” of domain concepts. aspect of the domain Eunjee Song Eunjee Song Software Requirements - 11 Software Requirements - 12 2

Problem vs. Solution views A Domain Model Does Not  A problem can be expressed as: Represent Software Objects  A difficulty the users or customers are facing  An opportunity that will result in some benefit such as improved productivity or sales. 1  The solution to the problem entails developing Rents 4 1.. * software software Customer VideoStore Video Rents-from 4 Stocks 4  Software designs and their implementations in address address 1 * name name ID * 1 source code describe solutions phoneNumber phoneNumber  Sometimes enforcing a sharp distinction A domain class model of a Video Store between requirements and design can be counterproductive ! Eunjee Song Software Requirements - 13 Eunjee Song Software Requirements - 14 Problem Decomposition Defining the Scope of the Problem Narrow the scope by defining a more precise problem   List all the things you might imagine the system doing  Sometimes called partitioning or problem  Exclude some of these things if too broad elaboration  Determine high-level goals if too narrow  Once scope is defined …  It is decomposed into constituent functions/parts Example: A university registration system   Input and output data objects are identified Initial list of problems Narrowed Scope of  Decomposition help domain expert to understand with very broad scope scope another system the problem browsing courses browsing courses room allocation room allocation registering registering exam scheduling exam scheduling fee payment fee payment Eunjee Song Eunjee Song Software Requirements - 15 Software Requirements - 16 Requirements types FURPS (A requirements categorization)  Functional requirements  Functionality  Describe what the system should do (i.e., behaviors) features, security, capabilities   Non-Functional  Usability  everything else (e.g., C onstraints that must be adhered human interaction factors, help system, documentation  to during development)  Reliability y  Examples E l frequency of failure, recoverability, predictability   the software must restrict access to sensitive  Performance information response times, throughput, accuracy, resource usage   the software must deliver a response within a time  Supportability interval after a particular event has occurred adaptability, maintainability, internationalization, configurability   the software must be usable by persons who are not computer literate. Eunjee Song Eunjee Song Software Requirements - 17 Software Requirements - 18 3

Describing Functional Requirements FURPS+  What inputs the software should accept  Implementation  Resource limitations, languages, tools, hardware  What outputs the software should produce  Interface  External system pluggins  What data the software should store that other systems might use systems might use  Operation O ti  System management in its operational setting  What computations the software should perform  Legal  Licensing, leveraging open-source  What are the timing and synchronization of the above Eunjee Song Software Requirements - 19 Eunjee Song Software Requirements - 20 Key Requirements Models Non-Functional Requirements Three main types Categories reflecting: usability, efficiency, reliability, maintainability  Use Cases: Describe required functionality  and reusability: Response time, Throughput, Resource usage, Reliability, Availability,  Requirements Class Models: Identify problem  Recovery from failure, Allowances for maintainability and enhancement, Allowances for reusability concepts and their relationships Categories constraining the environment and technology of the  software software.  Technical/data dictionary: describes domain  Technical/data dictionary: describes domain Platform  concepts Technology to be used  Categories constraining the project plan and development methods  Development process (methodology) to be used  Cost and delivery date  Often put in contract or project plan instead  Eunjee Song Eunjee Song Software Requirements - 21 Software Requirements - 22 4