Software analysis

2. Software analysis • What the software under development is supposed to do? • Understand the scope • Capturing user’s requirements • Identifying constraints • Understanding interfaces with entities, users and external systems • Should be design independent and detailed enough • Validated by client and developers

4. Requirements • First step in the analysis phase • Functional and non-functional requirements • Requirements engineering process starting from product vision and project scope • Use case model approach for capturing user requirements

5. Product vision and project scope • Establish business requirements and aligning them with software requirements specs • Clear vision and scope lead to more focused requirements • Document contains 3 sections: • Business requirements and context • Product vision • Project scope and limitations

7. Business requirements and context • Brief description of the rationale and business opportunity for the product to be developed. • Main business objectives and some quantifiable success criteria for these objectives. • Business objectives can refer to quantifiable financial or technical benefits to the target customers that are preferably quantifiable. • A quantifiable financial benefit is: “The product helps reducing the customer support cost by 30% during the first year of operations”. • A quantifiable technical benefit is: “The average delay to deal with and service a customer complaint will be around 8 hours”.

8. Business requirements and context (2) • Business risks associated with the business requirements and their management. • Risk assessment, prioritization, monitoring, mitigation and control. Detailed elaboration on the technical and non-technical project risks will be included in the software project plan document as will be discussed later in Chapter 10. • Description of the different types of product users and other stakeholders. • Context and environment in which the product will be operating. • The operating context and environment will later determine many of the non-functional product quality requirements such as security, performance, availability, and business continuity requirements.

9. Product vision • Clear statement of the product goals. • Capture the views of possibly many stakeholders and types of users, and show the financial and non-financial business benefits • Identify main functionalities and product features • List all the assumptions and dependencies • help identifying and reducing the risks, and clarifying constraints to various project and product stakeholders. • external conditions that have to be met: e.g. availability of a hardware device to interface with.

10. Project scope and limitations • List functionalities and features to be included in different releases or versions of the product. • Scope for each release is developed in line with the stakeholders’ objectives and priorities. • eliminating future misunderstandings between developers and clients. • Limitations include the functionalities and features that will not be provided by the product in any of its future releases. • clarify the expectations and functional boundaries of the product • reduce possible future conflicts between various product stakeholders.

11. Requirements engineering • Bad requirements => bad product • Need for a formal and structured process for developing and managing requirements • Requirements development (engineering): • requirements elicitation: techniques for seeking, extracting, acquiring and documenting requirements • requirements analysis • requirements specification • requirements maintenance (part of configuration management)

12. Types of requirements • Functional requirements • Functionalities and services provided to users to meet their needs and to achieve business objectives • Tangible, visible • Non-functional requirements • Constraints on the provision of functional req’s • Quality requirements: system wide or function specific

13. Elicitation of functional requirements • Understand client’s needs and communicate them to developers • Extraction, discovery / invention, acquisition / elaboration of stakeholders needs • System analyst, business analyst, requirement engineer or requirement facilitator • Under and over specification of requirements • Understand application domain, identify sources of requirements and stakeholders, selection of elicitation techniques

14. Elicitation techniques • Interviews • Questionnaires • Task analysis and scenarios • Preliminary requirements domain analysis • Brainstorming • Workshops • Meetings • Prototyping • Ethnographic assessment: observing, practicing

16. Interview technique • Informal technique used at the beginning of the elicitation process to engage the various participants. • Individual interviews are used to establish the initial mission statement and goals of the system being developed. • Interviews can be structured, unstructured, or hybrid. • Structured - requires a set of questions prepared ahead of time and distributed to the participants before the interview. • Unstructured - questions are developed dynamically as the interview progresses. • Hybrid - formatted with a set of fixed questions and impromptu questions that are asked during the interviews. • Careful formulation of interview questions is needed to avoid negative impact on the participants.

17. Questionnaire technique • Used at the beginning of the elicitation process to poll the participants and stakeholders and to obtain their thoughts on issues related to the system. • Questions must be clear, concise, and appropriate to the issues of the project • multiple choice, true and false, or open-ended questions. • Answers can be used by the requirements engineer to identify initial conflicting requirements requests that need to be resolved later.

18. Task analysis technique • Identification of the system uses and the description of the interactions between the users and the system. • Interactions can be described using scenarios or flow of events. • Top-down analysis: • first high level system tasks are identified. • then refined into lower level tasks and sub-tasks for which scenarios have to be elicited. • Task analysis requires domain knowledge expertise and an understanding of the tasks performed by similar systems.

19. Preliminary requirements • Preliminary requirements and domain analysis techniques start from an initial set of requirements. • Preliminary requirements are proposed by the expert requirements engineer and are passed to the various stakeholders for discussion. • The engineer must be an authority in the domain of application.

20. Group meeting technique • A group meeting includes all participants and stakeholders to start the elicitation process. • The formation of the group and the dynamics of the interactions among group participants are crucial for the success of this technique. • Cohesiveness, openness, and transparency are key communications features during group meetings.

21. Brainstorming technique • Based on brainstorming sessions: informal meetings to discuss the desirable functionalities and services • Inventive ideas that might or might not be feasible are generated. • All ideas are encouraged and the merits are discussed by the requirements analyst and other participants later in more formal settings. • The end product is an initial set of software requirements.

22. Workshop technique • Formal settings used to elicit software requirements. • Participants -a facilitator, a technical writer, the requirements engineer,and representatives from the client and users’ groups. • The aim is to reach an agreement on a working draft of the soft ware requirements. • Must be prepared thoroughly ahead of time and expectations from each participant must be explicitly • known. • Elicit best case and worst case scenarios and fit them in the various use cases of the use case model.

23. Ethnographic assessment technique • Used by the requirements engineer to gain a greater understanding of the problem domain. • It relies on the active or passive participation of the engineer in the working of similar systems and their user interfaces. • Active: by learning from the users’ activities by going through the various scenarios and business flows. • Passive: by observing the users’ activities without any interference. • Engineer acts as the apprentice and the user acts as the master or supervisor.

24. Prototyping technique • Considered an effective tool for eliciting and validating requirements. The requirements engineer develops an initial prototype of the system. A prototype should show the main elements of the system functionalities. • A prototype must be easy to develop and modify with little investment. The prototype must be evaluated and modified interactively with the users’ input. • Experience shows that prototype-based requirements are faster to elicit and include fewer errors than requirements developed using other elicitation techniques.

25. Use case modeling • Eliciting functional requirements by constructing a use case based requirements model. • The identification of the use case model is performed using various elicitation techniques. • Elicitation of actors, scenarios, use cases and their relationships • Use case diagrams (UCD) are developed.

26. Use case diagram • Actors – someone or something interacting with system and expects some useful results from it • Represented by a stickman • Entities external to system • People • Primary (triggering) and secondary actors • Use case satisfy some FRs and NFRs • Represented by an oval • Includes steps to be followed

27. Use Case Diagram relationships • A UCD is made of actors, use cases and interrelationships among actors and use cases: • <<communicates>> • <<extend>> • <<include>> • generalization (inheritance)

28. Relationships • <<communicate>> - linking a use case and an actor – represents interactions • <<extend>> -linking use cases – represents one use case interrupted by another user case under certain conditions • <<include>> - linking use cases – represents the inclusion of the steps of one use case in the other user case steps • Generalization or inheritance relationship among actors and among use cases (type-of relationship)

29. Actors: Resident (primary actor) and Alarm System Use case: Activate Alarm Two <<communicate>> relationships

32. Example • Consider the following English description of the Online Publisher Storefront (OPS). The OPS is a software system developed primarily to allow buyers to place book orders online. Buyers can be individual buyers or institutional buyers, for example, bookstore managers. Individual buyers have to supply payment information when they place their orders. Also, if registered, and after making purchases for more than $1000, they have special discounts and limited credit facility. However, institutional buyers must be pre-registered and must have a good credit standing. Buyers credit facilities and discounts are substantial.

33. Once an order is placed, the credit of the buyer is checked by the finance department and the order becomes active if the credit is in good standing. The order is then sent to the order fulfillment department for processing. Once the order is placed, the buyer has 24 hours to cancel or modify the order. The order fulfillment department is informed accordingly. When the order is placed, modified, or cancelled, the buyer is notified by an email that includes the order number in question. Once an order is fulfilled, it becomes a sale. Prior to placing an order, buyers normally browse the OPS catalogues to search for and select books and then place them in their electronic basket.

34. The content of the electronic basket can be modified at any time prior to the user placing the order. Before confirming an item in the basket, the system checks for its availability in the warehouse. Buyers can enquire about their orders using the order number. Additionally, users can e-mail a complaint or complete a form to complain about the quality of the service or dissatisfaction with the books they have received. The complaints are saved and dealt with by the OPS management staff . Managers and staff of OPS are registered users with two sets of privileges. Managers can modify the book catalogues and create, delete, and modify the staff records. Managers can also generate monthly reports for online sales. Registered users can enquire about their orders, view their purchasing history, and change their personal information.

35. Nouns and noun phrases • catalogue • book • electronic basket • user • item • warehouse • complaint • form • quality of the service • management staff • sets of privileges • staff records • monthly report • purchasing history • personal information • OPS • software system • buyer • book order • individual buyers • institutional buyer • bookstore manager • payment information • purchase • special discount • limited credit facility • good credit standing • finance department • order fulfillment department • email, order number

40. Use case development • Template for describing use cases • Reducing the complexity of use cases • Use <<include>> relationships • Modular use cases