REQUIREMENTS ENGINEERING PROCESS Lecture 4 Requirements A requirement

REQUIREMENTS ENGINEERING PROCESS Lecture 4

Requirements • A requirement is defined as: – A condition or capability needed by a user to solve a problem or achieve an objective; • A condition or a capability that must be met or possessed by a system … to satisfy a contract, standard, specification, or other formally imposed document …” IEEE 830 -1993 • The primary measure of success of a software system is the degree to which it meets the purpose for which it was intended. – Broadly speaking, software systems requirements engineering (RE) is the process of discovering that purpose, by identifying stakeholders and their needs, and documenting these in a form that is amenable to analysis, communication, and subsequent implementation. » Bashar Nuseibeh Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 2

Requirements Engineering • The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed. – The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering process. • Requirements Type: – User requirements • Statements in natural language 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’s functions, services and operational constraints. • Defines what should be implemented so may be part of a contract between client and contractor. Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 3

Challenges to Requirements • There a number of inherent difficulties in RE process: – Stakeholders may be numerous and distributed. – Stakholder’s goals may vary and conflicting • Depending on their perspectives of the environment in which they work and the tasks they wish to accomplish. – Stakeholder’s goals may not be explicit or may be difficult to articulate: • satisfaction of these goals may be constrained by a variety of factors outside their control. – Limitation of natural language • Ambiguity, consistency, understandability – – Writing vs reading Verity of methods Controlling/ managing/ tracing changes validation Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 4

Challenges to Requirements • So Many “Requirements”… – A goal is an objective or concern used to discover and evaluate functional and non-functional requirements. • A goal is not yet a requirement… – A functional requirement is a requirement defining functions of the system under development • Describes what the system should do – A non-functional requirement is a requirement characterizing a system property such as expected performance, robustness, usability, maintainability, etc. • Constraints that must be adhered to during development – A user requirement is a desired goal or function that a user and other stakeholders expect the system to achieve • Does not become necessarily a system requirement – A domain requirement is a requirement derived from the application domain • Can be functional or non-functional – Product Requirement – Process requirement – Security Requirements Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 5

Challenges to Requirements • Elicitation Risks and Challenges – Problems of scope • System boundaries inadequately defined or defined too soon • Unnecessary technical details – Problems of understanding • Stakeholder not sure of what is needed • Stakeholder has trouble communicating needs • Stakeholder does not understand capabilities and limitation of computing environment • Stakeholder does not have full understanding of domain • Stakeholders state conflicting requirements – Problems of volatility • Stakeholders will not commit to a set of written requirements Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 6

Challenges to Requirements • Elicitation Risks and Challenges – Other typical issues • • • Experts seldom available Finding an adequate level of precision/detail Common vocabulary often missing Sometimes hidden Sometimes too obvious, implicit, ordinary… – Participants often lack motivation and resist to change • We need much efforts and discussion to come up with a common agreement and understanding Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 7

Software Requirement- SWEBOK Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 8

Requirements Engineering • “Requirements engineering is the branch of software engineering concerned with the “REAL-WORLD GOALS” for, functions of, and constraints on software systems. It is also concerned with the relationship of these factors to “PRECISE SPECIFICATIONS” of software behavior, and to their EVOLUTION OVER TIME AND ACROSS SOFTWARE FAMILIES. ” – Real world Goals: Motivate the development of a software system. • Represent the ‘why’ and ‘what’ of a system. – Precise Specification: Provide the basis for: • • Analyzing requirements, Validating (what stakeholders want), Defining what designers have to build, and Verifying that they have done so correctly upon delivery – Evolution over Time: Emphasizing the reality of a changing world and the need to reuse partial specifications, Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 9

Software requirements engineering • Process of determining what is to be produced in a software system • An important aspect of any software project, and is a general term used to encompass all the activities related to requirements. – The four specific steps in software requirements engineering are: • • Requirements Elicitation Requirements Analysis Requirements Specification Requirements Validation Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST Seems to be separate tasks but these four processes cannot be strictly separated and performed sequentially and repeatedly 10

RE Activities • Requirements elicitation – Requirements discovered through consultation with stakeholders • Requirements analysis and negotiation – Requirements are analyzed and conflicts resolved through negotiation • Requirements specification – A precise requirements document is produced • Requirements validation – The requirements document is checked for consistency and completeness • Requirements management Acknowledgement to the work of Karl Wiegers, Software Requirements – Needs and contexts evolve, and so do requirements! Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 11

Why Focus on Requirements • NIST (National Institute of Standards and Distribution of Technology's) Distribution of Effort to Fix Defects – 70 % of the defects are introduced in the specification phase Code – 30 % are introduced later in the technical solution process. Code Other Design 1% Requirements 7% 4% Requirements Other – Only 56% 5 % of the specification inadequacies are corrected 13%in 82% 10% the specification phase – 95 % are detected later in the project or after delivery where the cost for correction in average is 22 times higher compared to a correction directly in the specification effort. • The NIST report concludes that extensive testing is Design 27% essential, however testing detects the dominating • (Martin & Leffinwell) specification errors late in the process. Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 12

Standish CHAOS Report -2010 – “This year’s results show a marked decrease in project success rates, with 32% of all projects succeeding which are delivered on time, on budget, with required features and functions” – Jim Johnson, chairman of The Standish Group says: • “ 44% were challenged which are late, over budget, and/or with less than the required features and functions and 24% failed which are cancelled prior to completion or delivered and never used. ” – Five of the eight main factors for project failure deal with requirements: • • • incomplete requirements, low customer involvement, unrealistic expectations, changes in the requirements, and useless requirements. Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 13

RE Process and Related Activities Why? Identify Business Needs and Goals What? Derive User & Functional Requirements How? Design Solutions Time TIME Who? • When? Whether viewed at the systems level or the software level, RE Project Management Process is a multi-disciplinary, human-centred process. If-Then – Risk The tools and techniques used in RE draw upon a variety of Management Process disciplines, and the requirements engineer may be expected to master skills from a number of different disciplines. Does It? Where? Quality Management Process • RE must span the gap between the informal world of stakeholder needs, and the formal world of software behaviour, the key question over the use&of. Configuration formal methods is Management not whether to formalise, but when Component Process to formalise Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 14

Why • “If you don’t get the requirements right, it doesn’t matter how well you do anything else. ” One can end up doing a perfect job of building the wrong product. » Karl Wiegers (2004) • Issues that can have a negative impact – Incomplete requirements: • A software product that does not meet all of the customer and user’s needs. – Lack of user involvement: • if practitioners miss a stakeholder group – Requirements mix: • changes in the requirements after initially agreement, missing, poorly written or ambiguous requirements – Wasted resources: • Requirements errors results in 70 -85 percent of the rework – Gold plating: • Developer adds functionality that was not in the requirements specification – Inaccurate estimates: • Requirement defines the scope, scope help is schedule and cost estimation Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 15

“What”- Part of the Requirements • Requirements must be determined and agreed to by the Why the Software is being developed customers, users, and suppliers of a software product before the software can be built. • The requirements define the “what” of a software product: – What the software must do to add value for its stakeholders. • These functional requirements define the capabilities of the software product. – What the software must be to add value for its stakeholders. • These nonfunctional requirements define the characteristics, properties, or qualities that the software product must possess. • They define how well the product performs its functions. – What limitations there are on the choices that developers have when implementing the software. • The external interface definitions and other constraints define these limitations. Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 16

Who • Stakeholders who affect or are affected by the software product and therefore have some level of influence over the requirements for that software product. – The RE process consider all of the various stakeholder’s interest in context with one another. – Stakeholders • Acquirers – Purchasers & end users • Suppliers – Organization & Developers (requirement Analyst, designer, Developers, Testers & technical writer • Others – Legal or contract management, Government or regulator agencies & Society at large Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 17

Who • The first step in identifying the stakeholders is to make sure that one considers all of the potential stakeholders. • The following checklist can help in identifying potential stakeholders: – What types of people will use the software product? – What business activities are supported by the software product and who performs, or manages those activities? – Whose job will be impacted by the introduction of the new software product? – Who will receive the reports, outputs, or other information from the software product? – Who will pay for the software product? Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 18

Software Requirement- SWEBOK • Requirements Process – Process Actors • Stakeholders • • Process Support and Management – make the link between the process activities and the issues of cost, human resources, training, and tools. Requirements Sources – Goals. • (sometimes called ‘business concern’ or ‘critical success factor’) refers to the overall, high-level objectives of the software. – – – Domain knowledge. Stakeholders The operational environment. The organizational environment. Similar System Documents / regulation / SOPs Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 19

How • Software requirements engineering is a disciplined, processoriented approach to the definition, documentation, and maintenance of software requirements throughout the software development life cycle. – software requirements engineering is made up of two major processes: requirements development and requirements management. Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 20

How part of Requirements • Requirements Engineering: A Roadmap, Bashar Nuseibeh – The context in which RE takes place is usually human activity system and the problem owner are people. – Techniques for eliciting and modeling, drawn on cognitive and social sciences: • Cognitive Psychology – Provides an understanding of the difficulties people may have in describing their needs » domain experts often have large amounts of knowledge their answers to questions posed by requirements analysts may not match their behaviour. • Anthropology – Provides a methodological approach to observing human activities that helps to develop a richer understanding • Sociology – Provides an understanding of the political and cultural changes caused by computerization. • Linguistics – To avoid ambiguity and to improve understandability. Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 21

Eliciting Requirements • Elicitation Techniques – Traditional Techniques • Questionnaires and Surveys • Interviews • Analysis of existing documentation – Group Elicitation • Group brainstorming sessions • RAD (Rapid Application Development) • JAD (Joint Application Design) – Prototyping • Where there is great deal of uncertainty • Early feedback from stakeholders is needed Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST • Requirements to Elicit – Boundaries • Identify the high level boundaries of the system • Stakeholders and Use Cases depend on boundaries – Goals • Denote the OBJECTIVES a system must meet. • Eliciting High level goals early in development – High level goals (business goals) refined into lower level goals (technical goals) eventually operationalised in a system – Tasks • When it is difficult to articulate user requirements – Observe, case studies, scenarios 22

Sources of Requirements • Various stakeholders – Clients, customers, users (past and future), managers, domain experts, developers, marketing and QA people, lawyers, auditors, anyone who can bring added value! • Pre-existing systems – Not necessarily software systems • • Pre-existing documentation Competing systems Documentation about interfacing systems Standards, policies, collective agreements, legislation Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 23

Comparison of some techniques Technique Good for Kind of data Plus Minus Answering specific questions Quantitative and qualitative data Can reach many people with low resource The design is crucial. Response rate may be low. Responses may not be what you want Exploring issues Some quantitative but mostly qualitative data Interviewer can guide interviewee. Encourages contact between developers and users Time consuming. Artificial environment may intimidate interviewee Collecting multiple viewpoints Some quantitative but mostly qualitative data Highlights areas of consensus and conflict. Encourages contact between developers and users Possibility of dominant characters Naturalistic observation Understanding context of user activity Qualitative Observing actual work gives insight that other techniques cannot give Very time consuming. Huge amounts of data Studying documentation Learning about procedures, regulations, and standards Quantitative No time commitment from users required Day-to-day work will differ from documented procedures Questionnaires Interviews Focus groups and workshops Adv Software Engg, MSCS 19, by Asst Prof Acknowledgment: Athar Mohsin, MCS-NUSTPreece, Rogers, and Sharp “Interaction Design: Beyond human-computer interaction”, p 214 24

Software Requirement- SWEBOK • Product Requirements – Requirements on software to be developed • The software shall verify that a student meets all prerequisites before he or she registers for a course • Process Requirements – A constraint on the development of the software • The software shall be written in C#. – Imposed directly by the development organization, their customer, or a third party such as a safety regulator • Functional Requirements – Describe the functions that the software is to execute – AKA Capabilities • Non-Functional Requirements – The ones that act to constrain the solution AKA Constraints Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 25

Software Requirement- SWEBOK • Emergent Properties – Requirements which cannot be addressed by a single component, but which depend for their satisfaction on how all the software components interoperate. • Quantifiable Requirements – To avoid vague and unverifiable requirements which depend for their interpretation on subjective judgment • The software shall be reliable’ • ‘The software shall be user-friendly’ • System Requirements – An interacting combination of elements to accomplish a defined objective. • Software requirements are derived from system requirements. Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 26

Functional Requirements – What inputs the system should accept – What outputs the system should produce – What data the system should store that other systems might use – What computations the system should perform – The timing and synchronization of the above – Examples: • The user shall be able to search either all of the initial set of databases or select a subset from it. • The system shall provide appropriate viewers for the user to read documents in the document store. • A user shall be able to search the appointments lists for all clinics. • The system shall generate each day, for each clinic, a list of patients who are expected to attend appointments that day. • Each staff member using the system shall be uniquely identified by his or her 8 -digit employee number. Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 27

Non-functional classifications • Product requirements – Requirements which specify that the delivered product must behave in a particular way • e. g. execution speed, reliability, etc. – The user interface for LIBSYS shall be implemented as simple HTML without frames or Java applets • Organisational requirements – Requirements which are a consequence of organisational policies and procedures • e. g. process standards used, implementation requirements, etc. – The system development process and deliverable documents shall conform to the process and deliverables defined in organization’s mission statement • External requirements – Requirements which arise from factors which are external to the system and its development process • e. g. interoperability requirements, legislative requirements, etc. – The system shall not disclose any personal information about customers apart from their name and reference number to the operators of the system. Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 28

Metrics for specifying nonfunctional requirements Property Measure Speed Processed transactions/second User/event response time/ Screen refresh time Size Mbytes Number of ROM chips Ease of use Training time Number of help frames Reliability Mean time to failure / Availability Probability of unavailability Rate of failure occurrence Robustness Time to restart after failure Percentage of events causing failure Probability of data corruption on failure Portability Percentage of target dependent statements Number of target systems

Domain requirements • The system’s operational domain imposes requirements on the system. – For example, a train control system has to take into account the braking characteristics in different weather conditions. • Domain requirements be new functional requirements, constraints on existing requirements or define specific computations. • If domain requirements are not satisfied, the system may be unworkable. • Problems – Understandability • Requirements are expressed in the language of the application domain; • This is often not understood by software engineers developing the system. – Implicitness • Domain specialists understand the area so well that they do not think of making the domain requirements explicit. Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 30

Requirements imprecision • Problems arise when requirements are not precisely stated. – Ambiguous requirements may be interpreted in different ways by developers and users. • Consider the term ‘search’ in following requirement – A user shall be able to search the appointments lists for all clinics. • User intention: – search for a patient name across all appointments in all clinics; • Developer interpretation: – search for a patient name in an individual clinic. User chooses clinic then search. Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 31

Requirements completeness and consistency • In principle, requirements should be both complete and consistent. – Complete • They should include descriptions of all facilities required. – Consistent • There should be no conflicts or contradictions in the descriptions of the system facilities. • In practice, it is impossible to produce a complete and consistent requirements document. Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 32

The software requirements document • The software requirements document is the official statement of what is required of the system developers. – Should include both a definition of user requirements and a specification of the system 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. Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 33

Requirements specification • The process of writing the user and system requirements in a requirements document. – User requirements have to be understandable by endusers and customers who do not have a technical background. – System requirements are more detailed requirements and may include more technical information. • The requirements may be part of a contract for the system development – It is therefore important that these are as complete as possible. Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 34

Ways of writing a system requirements specification Notation Description Natural language The requirements are written using numbered sentences in natural language. Each sentence should express one requirement. Structured language natural The requirements are written in natural language on a standard form or template. Each field provides information about an aspect of the requirement. Design description languages This approach uses a language like a programming language, but with more abstract features to specify the requirements by defining an operational model of the system. This approach is now rarely used although it can be useful for interface specifications. Graphical notations Graphical models, supplemented by text annotations, are used to define the functional requirements for the system; UML use case and sequence diagrams are commonly used. Mathematical specifications These notations are based on mathematical concepts such as finite-state machines or sets. Although these unambiguous specifications can reduce the ambiguity in a requirements document, most customers don’t understand a formal specification. They cannot check that it represents what they want and are reluctant to accept it as a system contract

Structure of a Good Requirement Defines a subject Shall or should verb “The system shall allow the Internet user to access his current account balance in less than 5 seconds. ” Defines a positive end result Performance criteria • This requirement sentence identifies a specific subject and end result that is wanted within a specified time that is measurable. – The challenge is to seek out the subject, end result, and success measure in every requirement you define! Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 36

Example of a Bad Requirement Cannot write a requirement on the user No identifier for the verb “The Internet user quickly sees the balance of her account on the laptop screen. ” Vague quality criterion Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST What versus how 37

Standard for Writing a Requirement –Each requirement must first form a complete sentence • Not a bullet list of buzzwords –Each requirement contains a subject and predicate • Subject: a user type or the system under discussion • Predicate: a condition, action, or intended result. –Consistent use of the verb: • “shall, ” “will”, or “must” to show mandatory nature • “should” or “may” to show optionality • Usually, shall and should are used. –A requirement contains a success criterion or other measurable indication of the quality. –A requirement describes what must be done, rather than how. Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 38

Writing errors to Avoid • Never describe how the system is going to achieve something (over-specification), always describe what the system is supposed to do –Refrain from designing the system • Danger signs: using names of components, materials, software objects, fields & records in the user or system requirements –Designing the system too early may possibly increase system costs –Do no mix different kinds of requirements (e. g. , requirements for users, system, and how the system should be designed, tested, or installed) –Do not mix different requirements levels (e. g. , the system and subsystems) • Danger signs: high level requirements mixed in with database design, software terms, or very technical terms Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 39

Writing errors to Avoid • “What versus how” test The system shall use Microsoft Outlook to send an email to the customer with the purchase confirmation. X The system shall inform the customer that the purchase is confirmed. Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 40

Writing errors to Avoid • Never build in let-out or escape clauses –Requirements with let-outs or escapes are dangerous because of problems that arise in testing –Danger signs: if, but, when, except, unless, although • These terms may however be useful when the description of a general case with exceptions is much clearer and complete that an enumeration of specific cases • Avoid ambiguity –Write as clearly and explicitly as possible –Ambiguities can be caused by: • The word or to create a compound requirement • Poor definition (giving only examples or special cases) • The words etc, …and so on (imprecise definition) Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 41

Writing errors to Avoid • Do not use vague indefinable terms – Many words used informally to indicate quality are too vague to be verified – Danger signs: user-friendly, highly versatile, flexible, to the maximum extent, approximately, as much as possible, minimal impact X The Easy Entry System shall be easy to use and require a minimum of training except for the professional mode. Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 42

Writing errors to Avoid • Do not make multiple requirements – Keep each requirement as a single sentence – Conjunctions (words that join sentences together) are danger signs: and, or, with, also • Do not use – Long sentences with arcane language – References to unreachable documents X The Easy Entry Navigator module shall consist of order entry and communications, order processing, result processing, and reporting. The Order Entry module shall be integrated with the Organization Intranet System and results are stored in the group’s electronic customer record. Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 43

Writing errors to Avoid • Do not speculate – There is no room for “wish lists” – general terms about things that somebody probably wants – Danger signs: vague subject type and generalization words such as usually, generally, often, normally, typically • Do not express suggestions or possibilities – Suggestions that are not explicitly stated as requirements are invariably ignored by developers – Danger signs: may, might, should, ought, could, perhaps, probably • Avoid wishful thinking – Wishful thinking means asking for the impossible (e. g. , 100% reliable, safe, handle all failures, fully upgradeable, run on all platforms) X The Easy Entry System may be fully adaptable to all situations and often require no reconfiguration by the user. Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 44

Requirements problem example • “LIBSYS will be configurable so that it will comply with the requirements of international copyright legislation. Minimally, this means that LIBSYS must provide a form for the user to sign the Copyright Declaration statement. It also means that LIBSYS must keep track of Copyright Declaration statements which have been signed/not-signed. Under no circumstances must an order be sent to the supplier if the copyright statement has not been signed. ” Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST Dig out the problems in this requirement 45

Problems in example requirement • Incompleteness – – What international copyright legislation is relevant? What happens if the copyright declaration is not signed? If a signature is a digital signature, how is it assigned? Recommendation: • Define all copyright legislation as a separate requirement • Reword requirement as “ copyright declaration must be signed before order is complete • Introduce a new requirement for signature assignment • Ambiguity – What does signing an electronic form mean? Is this a physical signature or a digital signature? • Define what is meant by “signature” • Standards – More than 1 requirement. Maintenance of copyright is one requirement; issue of documents is another • Split the requirements in two or three separate requirements Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 46

Acknowledgement • SWEBOK Chapter 4 • Requirements Engineering: A Roadmap – Bashar Nuseibeh • Software Requirements Engineering: What, Why, Who, When and How – Linda westfall • Chapter 4 Software Engineering 9 th edition – Ian Sommerville • Requirements Engineering – Kotonya & Sommerville Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 47