Business Model Canvas and Software Requirements Engineering.pdf

BUSINESS MODEL CANVAS PRESENTED BY: CENTINO, MARJORIE C.  INFLUENCE OF BMC ON SOFTWARE DEVELOPMENT WHY BMC MATTERS IN SOFTWARE DEVELOPMENT WHY BMC MATTERS IN SOFTWARE DEVELOPMENT Aligns software features with business goals. Ensures software solves the right customer proble...

BUSINESS MODEL CANVAS PRESENTED BY: CENTINO, MARJORIE C.  INFLUENCE OF BMC ON SOFTWARE DEVELOPMENT WHY BMC MATTERS IN SOFTWARE DEVELOPMENT WHY BMC MATTERS IN SOFTWARE DEVELOPMENT Aligns software features with business goals. Ensures software solves the right customer problems. Guides development resources and costs. Enhances product delivery and customer satisfaction.  CLEAR UNDERSTANDING OF THE PROBLEM UNDERSTANDING CUSTOMER PROBLEMS Value Proposition: Defines the problem that the software must solve Ensures the development focuses on delivering value to the end- user. Helps developers design solutions that directly address customer pain points.  CUSTOMER-CENTRIC DEVELOPMENT DESIGNING WITH THE CUSTOMER IN MIND Customer Segments: Identifies the target audience for the software. Guides decisions on user interface, experience, and features. Ensures different user groups are considered in the software’s design.  RESOURCE AND COST MANAGEMENT OPTIMIZING RESOURCES AND COSTS Key Resources and Cost Structure: Dictate available technologies, tools, and budget. Helps balance quality and budget constraints. Ensures development remains cost-effective while delivering required functionality.  EFFECTIVE PRODUCT DELIVERY DELIVERING THE PRODUCT TO THE RIGHT AUDIENCE Channels: Defines how the software will reach the user (web, mobile, third-party platforms). Ensures developers build software that fits the business’s delivery strategy. Customer Relationships: Guides support and post-launch features.  REVENUE-DRIVEN FEATURES SUPPORTING BUSINESS REVENUE Revenue Streams: Ensures the software aligns with the business’s monetization strategy. Guides feature development for freemium, subscription, or in-app purchases. Helps prioritize high-value features.  ITERATIVE DEVELOPMENT & INNOVATION ENCOURAGING CONTINUOUS IMPROVEMENT Key Partners and Key Activities: Foster partnerships that enable quicker development. Promotes continuous improvement through integration with third-party tools. Encourages innovative solutions to optimize the development process.  RISK MANAGEMENT MITIGATING RISKS IN DEVELOPMENT Key Partners and Cost Structure: Help identify potential risks (e.g., technology limitations). Enables early risk mitigation by aligning development with business stability. Supports proactive decision-making to prevent issues during software development.  SOFTWARE REQUIREMENTS ENGINEERING UNDERSTANDING AND DEFINING SOFTWARE REQUIREMENTS SOFTWARE REQUIREMENTS The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed Requirements may be functional or non-functional Functional requirements describe system services or functions Non-functional requirements is a constraint on the system or on the development process. WHAT IS A REQUIREMENT? It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification This is inevitable as requirements may serve a dual function May be the basis for a bid for a contract - therefore must be open to interpretation May be the basis for the contract itself - therefore must be defined in detail Both these statements may be called requirements  TYPES OF REQUIREMENTS USER REQUIREMENTS Statements in natural language (NL) plus diagrams of the services the system provides and its operational constraints. Written for customers SYSTEM REQUIREMENTS A structured document setting out detailed descriptions of the system services. Written as a contract between client and contractor SOFTWARE SPECIFICATION A detailed software description which can serve as a basis for a design or implementation. Written for developers REQUIREMENTS TARGETS  REQUIREMENTS TYPES: FUNCTIONAL REQUIREMENTS: services the system should provide NON-FUNCTIONAL REQUIREMENTS: constraints on the services of functions offered by the system. e.g. speed, time to market DOMAIN REQUIREMENTS: related to the application domain of the system (may be functional or non- functional requirements)  FUNCTIONAL REQUIREMENTS Functionality or services that the system is expected to provide. Functional requirements may also explicitly state what the system shouldn’t do. Functional requirements specification should be: Complete: All services required by the user should be defined Consistent: should not have contradictory definition (also avoid ambiguity, don’t leave room for different interpretations)  NON-FUNCTIONAL REQUIREMENTS Requirements that are not directly concerned with the specific functions delivered by the system Typically relate to the system as a whole rather than the individual system features Often could be deciding factor on the survival of the system (e.g. reliability, cost, response time) NON-FUNCTIONAL REQUIREMENTS CLASSIFICATIONS:  DOMAIN REQUIREMENTS Domain requirements are derived from the application domain of the system rather than from the specific needs of the system users. May be new functional requirements, constrain existing requirements or set out how particular computation must take place. Example: tolerance level of landing gear on an aircraft (different on dirt, asphalt, water), or what happens to fiber optics line in case of sever weather during winter Olympics (Only domain- area experts know)  PROBLEMS WITH NATURAL LANGUAGE Lack of clarity Precision is difficult without making the document difficult to read Requirements confusion Functional and non-functional requirements tend to be mixed-up Requirements amalgamation Several different requirements may be expressed together Ambiguity The readers and writers of the requirement must interpret the same words in the same way. NL is naturally ambiguous so this is very difficult Over-flexibility The same thing may be said in a number of different ways in the specification  ALTERNATIVES TO NL SPECIFICATION Structured Natural language (via standard forms & templates) Program Description Language (PDL) Use-Cases (scenario-based technique) Mathematical specification (notations based on mathematical concepts such as finite-state machines or set.)  STRUCTURED LANGUAGE SPECIFICATIONS A limited form of natural language may be used to express requirements This removes some of the problems resulting from ambiguity and flexibility and imposes a degree of uniformity on a specification Often best supported using a form-based approach  PDL-BASED REQUIREMENTS DEFINITION Requirements may be defined operationally using a language like a programming language but with more flexibility of expression Most appropriate in two situations Where an operation is specified as a sequence of actions and the order is important When hardware and software interfaces have to be specified Example: ATM machine  PDL DISADVANTAGES PDL may not be sufficiently expressive to express the system functionality in an understandable way Notation is only understandable to people with programming language knowledge The requirement may be taken as a design specification rather than a model to help understand the system ATM SPECIFICATION: A PDL EXAMPLE  THE REQUIREMENTS DOCUMENT The requirements document is the official statement of what is required of the system developers Should include both a definition and a specification of requirements It is NOT a design document. As far as possible, it should set of WHAT the system should do rather than HOW it should do it  REQUIREMENTS ENGINEERING (RE) PROCESSES Processes used to discover, analyse and validate system requirements RE vary widely depending on the application domain, the people involved and the organization developing the requirements However, there are a number of generic activities common to all processes Requirements elicitation Requirements analysis Requirements validation Requirements management  PROBLEMS OF REQUIREMENTS ANALYSIS Stakeholders don’t know what they really want Stakeholders express requirements in their own terms Different stakeholders may have conflicting requirements Organizational and political factors may influence the system requirements The requirements change during the analysis process. New stakeholders may emerge and the business environment change USE CASE MODELING  USE CASES Use-cases are a scenario based technique in the UML which identify the actors in an interaction and which describe the interaction itself A set of use cases should describe all possible interactions with the system Sequence diagrams may be used to add detail to use-cases by showing the sequence of event processing in the system EXAMPLE THANK YOU FOR COMING