Professional Documents
Culture Documents
ENGINEERING
Daffodil International University
LEARNING
CONTENTS
OUTCOME
✔Analyze System Requirements For, ✔Requirement Engineering
✔Existing Systems
▪ More…
USER REQUIREMENTS & SYSTEM
REQUIREMENTS
▪ User requirements
▪ High-level abstract requirements
▪ Written as statements, in a natural language plus diagrams,
▪ services the system is expected to provide to system users
▪ constraints under which it must operate.
▪ System requirements
▪ Detailed description of system
▪ functions, services, and operational constraints.
▪ The system requirements document (sometimes called a functional
specification) should define exactly what is to be implemented.
FUNCTIONAL REQUIREMENTS
▪ Describe functionality or system services
▪ Depends on the type of software, expected users and the type of system where the
software is used
▪ High-level statements of what the system should do
▪ Describe the system services in detail
▪ Problems arise when-
▪ Requirements are not precise and interpreted in different ways by developers and users.
▪ In principle, requirements should be both
▪ Complete: include descriptions of all facilities required
▪ Consistent: should be no contradictions in descriptions
▪ In practice, it is impossible!
NON-FUNCTIONAL
REQUIREMENTS(1/2)
▪ System properties and constraints
▪ e.g. reliability, response time and storage requirements
▪ Organizational requirements
▪ Requirements which are a consequence of organizational 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.
DOMAIN REQUIREMENTS
▪ The system's operational domain imposes requirements on the system.
▪ Domain requirements may be new functional requirements, constraints on existing
requirements or define specific computations.
▪ If domain requirements are not satisfied, the system may be unworkable.
▪ Two main problems :
▪ Understandability
▪ Requirements are expressed in the language of the application domain, which is not always
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.
REQUIREMENTS ENGINEERING
PROCESS
▪ Processes vary widely depending on the application domain, the people involved
and the organization developing the requirements.
▪ In practice, requirements engineering is an iterative process in which the
following generic activities are interleaved:
▪ Requirements elicitation;
▪ Requirements analysis;
▪ Requirements validation;
▪ Requirements management.
ELICITATION AND ANALYSIS
▪ Range of system stakeholders
▪ Requirements discovery by interacting with stakeholders
▪ Requirements are grouped and organized into coherent clusters
▪ Prioritizing requirements and resolving requirements conflicts
▪ Requirements are documented and input into the next round of the spiral
▪ Problems :
▪ 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.
▪ Requirements change during the analysis process.(More on this…)
REQUIREMENTS SPECIFICATION AND
VALIDATION
▪ Requirements specification
▪ Writing down user and system requirements in a requirements document
▪ Written in natural language supplemented by appropriate diagrams and
tables
▪ Structured natural language is used to maintain a standard way.
▪ Requirements Validation
▪ Demonstrates that the requirements define the system that the customer really
wants
▪ Regular reviews should be held while the requirements definition is being
formulated
▪ Using an executable model of the system to check requirements
▪ Developing tests for requirements to check testability
REQUIREMENTS CHANGE
▪ Challenge-
▪ Requirements are ever changing
▪ Testing can reveal the presence of errors, but NOT their absence
▪ Testing is part of a more general verification and validation process
▪ Error
▪ the actual result deviates from the expected.
▪ Our expected results should (theoretically) come from our requirements definition.
▪ Most often, the goals/concerns/expectations of stakeholders serve as the testing basis.
TESTING(2/2)
▪ Test Case
▪ a set of inputs, execution conditions, and expected results for testing an object
▪ Scenario testing
▪ devise typical scenarios of use and use these to develop test cases for the system
▪ Scenarios should be realistic and real system users should be able to relate to them.
▪ If scenarios were developed as part of the requirements engineering process, it can
be reused as testing scenarios.
USER TESTING
▪ User or customer testing is a stage in the testing process in which users or customers
provide input and advice on system testing.
▪ User testing is essential, even when comprehensive system and release testing have
been carried out. Types of user testing include:
▪ Alpha testing:
▪ Users of the software work with the development team to test the software at the developer's site.
▪ Beta testing:
▪ A release of the software is made available to users to allow them to experiment and to raise
problems that they discover with the system developers.
▪ Acceptance testing:
▪ Customers test a system to decide whether or not it is ready to be accepted from the system
developers and deployed in the customer environment.
TEST METHODS AND
TECHNIQUES
▪ Link Testing : Finding broken links, orphan pages etc.
▪ Browser Testing : variety of browsers exists. Thus need to test.
▪ Load Testing: Does the system meet required response times and throughput?
▪ Stress Testing: How does the system behave under abnormal/extreme
conditions?
▪ Continuous Testing : Typically, running the operation a few times doesn’t
produce an error, hence the need for continuous testing.
▪ Security Testing:
▪ Is our SSL certificate working?
▪ What happens if I try to access a protected page/site in a non-secure way (i.e., http://)?
EXERCISE AND READINGS
▪ EXERCISE
▪ Develop SRS for you course project (soft copy submission)
▪ Write a short notes on
▪ Web Project Management
▪ Testing tools.
▪ READINGS
▪ Requirement Engineering
▪ https://cs.ccsu.edu/~stan/classes/CS410/Notes16/04-Requirements.html
▪ Software Testing
▪ https://cs.ccsu.edu/~stan/classes/CS410/Notes16/08-SoftwareTesting.html
▪ Project Management
▪ https://cs.ccsu.edu/~stan/classes/CS410/Notes16/22-ProjectManagement.html
▪ Testing tools
▪ https://medium.com/@briananderson2209/best-automation-testing-tools-for-2018-top-10-reviews-
8a4a19f664d2
REFERENCES
▪ Requirements Engineering
▪ Reference: Sommerville, Software Engineering, 10 ed., Chapter 4
▪ Testing
▪ Sommerville, Software Engineering, 10 ed., Chapter 8
▪ Project Management
▪ Sommerville, Software Engineering, 9 ed., Chapter 22
▪ https://www.researchgate.net/figure/Web-Engineering-A-multidisciplinary-
field_fig1_220795871
▪ https://www.quora.com/What-is-web-engineering