gg
Advantages: The cost of accommodating changing customer requirements is reduced.The amount of analysis and documentation that has to be redone is much less than is required with the waterfall model.It is easier to get customer feedback on the development work that has been done.Customers can comment on demonstrations of the software and see how much has been implemented.More rapid delivery and deployment of useful software to the customer is possible.Customers are able to use and gain value from the software earlier than is possible with a waterfall process. Disadvantages: The process is not visible.Managers need regular deliverables to measure progress. If systems are developed quickly, it is notcost-effective to produce documents that reflect every version of the system.System structure tends to degrade as new increments are added. Unless time and money is spent on refactoring to improve the software, regular change tends to corrupt its structure. Incorporating further software changes becomes increasingly difficult and costly. Throw-Away Prototypes:Prototypes should be discarded after development as they are not a good basis for a production system:It may be impossible to tune the system to meet non-functional requirements;Prototypes are normally undocumented;The prototype structure is usually degraded through rapid change;The prototype probably will not meet normal organizational quality standards.Incremental Delivery:Rather than deliver the system as a single delivery, the development and delivery is broken down into increments with each increment delivering part of the required functionality.User requirements are prioritized and the highest priority requirements are included in early increments.Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve.Refactoring.:Replacing the in-line code for Methods, to making the code as simple as possible to deliver the documentation because it must has to be every two weeks, also renaming the methods and all the attributes of the class and reorganize the class hierarchy Scaling out: Is concerned with using agile methods for developing large, software systems that cannot be developed by small team.Scaling up: Is concerned with how agile methods can be introduced across a large organization with many years of software experience.TypesofRequirementEngineering: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.Functional requirements:Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.May state what the system should not do.Non-functional requirements:Often apply to the system as a whole rather than individual features or services.Domain requirements:Constraints on the system from the domain of operation.RequirementAbstractionDavis’s view:“If a company wishes to let a contract for a large software development project, it must define its needs in a sufficiently abstract way that a solution is not pre-defined. The requirements must be written so that several contractors can bid for the contract, offering, perhaps, different ways of meeting the client organization’s needs. Once a contract has been awarded, the contractor must write a system definition for the client in more detail so that the client understands and can validate what the software will do. Both of these documents may be called the requirements document for the system.”For the Non-functional Requirements discuss the following: Properties and Constraints Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.Showtheblock diagramofdifferenttypes Non-functionReq.->((ProductReq->UsabilityRq,(EfficiencyReq->Performance&SpaceReq),DependabiltyRq,SecurityRq),(OrganizationalReq->EnvironmentalRq,OperationalRq,DevelopmentRq.),(ExternalReq.->RegulatoryReq,EthicalReq,(LegislativeReq->Accountint&safetyReq))Typeindetails:Product requirements:Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc.Organisational requirements:Requirements which are a consequence of organisational policies and procedures e.g. process standards used, implementation requirements, etc.External requirements:Requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc.Examplesofeachtypeinrealcase:Product requirement:The MHC-PMS shall be available to all clinics during normal working hours (Mon–Fri, 0830–17.30). Downtime within normal working hours shall not exceed five seconds in any one day.Organizational_requirement:Users of the MHC-PMS system shall authenticate themselves using their health authority identity card.External_requirement:The system shall implement patient privacy provisions as set out in HStan-03-2006-priv.