The document discusses requirements engineering and outlines several key points:
1) Requirements are early guesses about a project that can be difficult to get right, especially with multiple stakeholders involved who may have conflicting needs.
2) Lightweight notations are important for capturing requirements in a way that allows for fast writing and reasoning.
3) Getting requirements wrong can be extremely costly, so methods like feature mapping and the Decision Dependency Diagram are presented as ways to help systematically capture and analyze stakeholder needs.
Objectives:
1. To understand the different processes in the realm of ‘Requirements Engineering’.
2. To see the challenges in requirements development and the importance of getting requirements right in an IT project.
3. To understand the different techniques used in different phases and processes of requirements development and management.
In systems engineering and software engineering, requirements analysis encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product or project, taking account of the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating and managing software or system requirements.
Software Requirements and Specificationsvustudent1
CS510 - SRS handouts for Computer Science students of Virtual University of Pakistan.
Prepared by ForumVU.com Staff from the updated lectures and PowerPoint slides of CS510 - Software Requirements and Specifications in VU LMS.
Objectives:
1. To understand the different processes in the realm of ‘Requirements Engineering’.
2. To see the challenges in requirements development and the importance of getting requirements right in an IT project.
3. To understand the different techniques used in different phases and processes of requirements development and management.
In systems engineering and software engineering, requirements analysis encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product or project, taking account of the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating and managing software or system requirements.
Software Requirements and Specificationsvustudent1
CS510 - SRS handouts for Computer Science students of Virtual University of Pakistan.
Prepared by ForumVU.com Staff from the updated lectures and PowerPoint slides of CS510 - Software Requirements and Specifications in VU LMS.
Software Crisis
Software products:
fail to meet user requirements.
Software product
expensive.
difficult to alter, debug, and enhance.
often delivered late.
use resources non-optimally.
Factors contributing to the software crisis
Computer Systems Engineering
Software Life Cycle
Life Cycle Model
Software Crisis
Software products:
fail to meet user requirements.
Software product
expensive.
difficult to alter, debug, and enhance.
often delivered late.
use resources non-optimally.
Factors contributing to the software crisis
Computer Systems Engineering
Software Life Cycle
Life Cycle Model
Describes a model to analyze software systems and determine areas of risk. Discusses limitations of typical test design methods and provides an example of how to use the model to create high volume automated testing framework.
Modern life relies on good tech. Good tech relies on quality code. This presentation lays out the rationale and research behind my draft software quality certification tentatively named Quality+.
TLC2018 Thomas Haver: The Automation Firehose - Be Strategic and TacticalAnna Royzman
Thomas Haver teaches how to automate both strategically and tactically to maximize the benefits of automation - at Test Leadership Congress 2018.
http://testleadershipcongress-ny.com
For numerous large enterprises, the alignment of hardware and software processes is critical to managing an Agile environment. Agile Hardware implementations can be put in place by using the same framework as our typical Agile Software Development transformations. Start off with assessing the organization’s current state, then move to planning and preparing by and putting together a transition backlog, start execution with training and coaching, spread the cultural shift with change management and maintain and scale the transformation.
Agile Hacks: Creative Solutions for Common Agile IssuesTechWell
Whether you are just starting agile or have already made the transition to using agile in your organization, you may face the issues that Susan McNamara describes. Is your team not firing on all cylinders? Do people feel stuck or bored? Is your team having trouble getting to Done at the end of each sprint? Susan has booted up agile in three different organizations and has found valuable approaches that work across different environments. She covers topics including getting the most out of your product owners/product managers, dealing with organizational constraints in the agile group, encouraging good synergy between development and testers, and ways to keep the team mentally engaged. Based on her real-life experiences, Susan provides simple “agile hacks” that you and your team can use to solve these common problems and lift your team to the next level. Sometimes all you need are creative solutions to turn your team into agile heroes.
Bridging the Gap: from Data Science to ProductionFlorian Wilhelm
A recent but quite common observation in industry is that although there is an overall high adoption of data science, many companies struggle to get it into production. Huge teams of well-payed data scientists often present one fancy model after the other to their managers but their proof of concepts never manifest into something business relevant. The frustration grows on both sides, managers and data scientists.
In my talk I elaborate on the many reasons why data science to production is such a hard nut to crack. I start with a taxonomy of data use cases in order to easier assess technical requirements. Based thereon, my focus lies on overcoming the two-language-problem which is Python/R loved by data scientists vs. the enterprise-established Java/Scala. From my project experiences I present three different solutions, namely 1) migrating to a single language, 2) reimplementation and 3) usage of a framework. The advantages and disadvantages of each approach is presented and general advices based on the introduced taxonomy is given.
Additionally, my talk also addresses organisational as well as problems in quality assurance and deployment. Best practices and further references are presented on a high-level in order to cover all facets of data science to production.
With my talk I hope to convey the message that breakdowns on the road from data science to production are rather the rule than the exception, so you are not alone. At the end of my talk, you will have a better understanding of why your team and you are struggling and what to do about it.
Building and Scaling High Performing Technology Organizations by Jez Humble a...Agile India
High performing organizations don't trade off quality, throughput, and reliability: they work to improve all of these and use their software delivery capability to drive organizational performance. In this talk, Jez presents the results from DevOps Research and Assessment's five-year research program, including how continuous delivery and good architecture produce higher software delivery performance, and how to measure culture and its impact on IT and organizational culture. They explain the importance of knowing how (and what) to measure so you focus on what’s important and communicate progress to peers, leaders, and stakeholders. Great outcomes don’t realize themselves, after all, and having the right metrics gives us the data we need to keep getting better at building, delivering, and operating software systems.
More details:
https://confengine.com/agile-india-2019/proposal/8524/building-and-scaling-high-performing-technology-organizations
Conference link: https://2019.agileindia.org
Measure and Increase Developer Productivity with Help of Serverless at Server...Vadym Kazulkin
The goal of Serverless is to focus on writing the code that delivers business value and offload everything else to your trusted partners (like Cloud providers or SaaS vendors). You want to iterate quickly and today’s code quickly becomes tomorrow’s technical debt. In this talk we will show why Serverless adoption increases the developer productivity and how to measure it. We will also go through AWS Serverless architectures where you only glue together different Serverless managed services relying solely on configuration, minimizing the amount of the code written.
Join us as we walk you through several technical challenges and solutions around test automation for responsive sites. See live demos around testing responsive web sites using extended test automation capabilities that can increase your test coverage suite.
You'll learn how to:
- Author basic selenium scripts using a powerful recorder for both mobile and web
- Define a robust XPath using an innovative free online tool
- Build a test lab for parallel script Execution on multiple devices and browsers
- Gain high quality analysis post execution with mature digital reporting
10/17/19
1
EE 200: Electrical Engineering Design Project
Process AKA Systems Engineering
4
4
Dr. Haggerty, PE (EE)
• Guide you through
o Project Process
o Requirements Analysis
o Prototype Development
• 14 years: Systems Engineering
Aerospace and electronic systems
o Numerous winning proposals
o 100s M$ in new business
• 20 years: Consulting Engineer
o Broader technical
o Multiple large clients
o Multiple start-ups
• 5 Years Adjunct faculty
o Teach LD, UD, and Grad
o A “go to” replacement 5
5
10/17/19
2
Dr. Haggerty, PE (EE)
• Guide you through
o Project Process
o Requirements Analysis
o Prototype Development
• 14 years: Systems Engineering
Aerospace and electronic systems
o Numerous winning proposals
o 100s M$ in new business
• 20 years: Consulting Engineer
o Broader technical
o Multiple large clients
o Multiple start-ups
• 5 Years Adjunct faculty
o Teach LD, UD, and Grad
o A “go to” replacement 2
Elevator Pitch is Short Explanation to Catch
Listeners Interest
Individual
• Name
• Project Role
• Experience Summary
• 15𝑠 ≤ 𝑇&' ≤ 2𝑚𝑖𝑛
6• References on BeachBoard
6
Project/Product:
• Product Elevator Pitch Outline
o Hook:
o Who it is for:
o What it does:
o Why it is needed:
• What would differentiate
your product ?
o (To help generate info for
Elevator Pitch)
7
7
10/17/19
3
They say there is
no “I” in Team.
9
9
Engineering Project Process Defined in:
HF Hoffman, The Engineering Capstone Course
Part 1
• Select team and project
• Analyze business case and issues
• Unit specifications
• Parts list and purchase
• Test planning
• Proposal
Part 2
• Weekly status
• Formal team meetings
• Formal design reviews
• Software design, code, and test
• Hardware design, fabrication, and
integration
• Software/hardware integration
• Final report, presentation, and
demonstration of final product
10
10
10/17/19
4
Systems Engineering Made up of Technical
and Managerial Functions
Technical
• Requirements Analysis
• System Architecture/Design
• Performance Analysis
• Interface Specification
• Test
o Verification and Validation
o AKA V&V
Managerial
• Customer Interface
• Technical Management
• Information Management
Process Engineering
• Logistics and Operations
• Coordination
11
11
Validation Shows Product Meets User Needs
Verification Shows Design Meets Requirements
14
14
10/17/19
5
15
Full V&V Systems Engineering
Example: NASA Systems Engineering Handbook
15
Tailored Process Flow Guides You Through
Streamlined Product Prototype Development
16
System Requirements
• Specific statements
• One shall per req
• Independent of Design
• What Not How
Acceptance Tests
• For each System Req
• Tests System at End
Design and Development
Requirements Analysis
• Technical Objectives
• Constraints Worksheet
• Standards Usage
Integration and Test
• Hardware Unit
• Software Module
• HW/SW
HW/SW Partitioning
Hardware
• Req Trace
• Design
• Fabrication
Software
• Req Trace
• Design
• Code
P
Science has escaped the lab and is roaming free in the world. People use software to understand the world . What tools are needed to support that work?
GALE: Geometric active learning for Search-Based Software EngineeringCS, NcState
Multi-objective evolutionary algorithms (MOEAs) help software engineers find novel solutions to complex problems. When automatic tools explore too many options, they are slow to use and hard to comprehend. GALE is a near-linear time MOEA that builds a piecewise approximation to the surface of best solutions along the Pareto frontier. For each piece, GALE mutates solutions towards the better end. In numerous case studies, GALE finds comparable solutions to standard methods (NSGA-II, SPEA2) using far fewer evaluations (e.g. 20 evaluations, not 1,000). GALE is recommended when a model is expensive to evaluate, or when some audience needs to browse and understand how an MOEA has made its conclusions.
Three Laws of Trusted Data Sharing:(Building a Better Business Case for Dat...CS, NcState
Discussions about sharing
- Too much fear
- Not enough about benefits
Can we learn more from sharing that hoarding ?
- Yes (results from SE)
Three laws of trusted data sharing:
- For SE quality prediction..
- Better models from shared privatized data that from all raw data
Q: does this work for other kinds of data?
A: don’t know… yet
172529main ken and_tim_software_assurance_research_at_west_virginiaCS, NcState
SA @ WV(software assurance research at West Virginia)
Kenneth McGill
NASA IV&V Facility Research Lead
304.367.8300
Kenneth.McGill@ivv.nasa.gov
Dr. Tim Menzies Ph.D. (WVU)
Software Engineering Research Chair
tim@menzies.us
Next Generation “Treatment Learning” (finding the diamonds in the dust)CS, NcState
Q: How have dummies (like me) managed to gain (some) control over a (seemingly) complex world?
A:The world is simpler than we think.
◆ Models contain clumps
◆ A few collar variables decide which clumps to use.
ICSE’14 Workshop Keynote Address: Emerging Trends in Software Metrics (WeTSOM’14).
Data about software projects is not stored in metrc1, metric2,…,
but is shared between them in some shared, underlying,shape.
Not every project has thesame underlying simple shape; many projects have different,
albeit simple, shapes.
We can exploit that shape, to great effect: for better local predictions; for transferring
lessons learned; for privacy-preserving data mining/
In the age of Big Data, what role for Software Engineers?CS, NcState
ABSTRACT:
Consider the premise of Big Data:
better conclusions = same algorithms + more data + more cpu
If this were always true, then there would be no role for human analysts
that reflected over the domain to offer insights that produce better solutions
(since all such insight is now automatically generated from the CPUs).
This talk proposes a marriage of sorts between Big Data and software
engineering. It reviews over a decade of work by the author in exploring
user goals using CPU-intensive methods. It will be shown that analyst-insight was
useful from building “better" tools (where “better” means generate
more succinct recommendations, runs faster, scales to much larger problems).
The conclusion will be that in the age of big data, human analysis is still
useful and necessary. But a new kind of software engineering analyst is required- one
that know how to take full advantage of the power of Big Data.
ABOUT THE AUTHOR:
Tim Menzies (P.hD., UNSW) is a Professor in CS at WVU; the author of
over 230 referred publications; and is one of the 50 most cited
authors in software engineering (out of 50,000+ researchers, see
http://goo.gl/wqpQl). At WVU, he has been a lead researcher on
projects for NSF, NIJ, DoD, NASA, USDA, as well as joint research work
with private companies. He teaches data mining and artificial
intelligence and programming languages.
Prof. Menzies is the co-founder of the PROMISE conference series
devoted to reproducible experiments in software engineering (see
http://promisedata.googlecode.com). He is an associate editor of IEEE
Transactions on Software Engineering, Empirical Software Engineering
and the Automated Software Engineering Journal. In 2012, he served as
co-chair of the program committee for the IEEE Automated Software
Engineering conference. In 2015, he will serve as co-chair for the
ICSE'15 NIER track. For more information, see his web site
http://menzies.us or his vita at http://goo.gl/8eNhY or his list of
pubs at http://goo.gl/0SWJ2p.
Acetabularia Information For Class 9 .docxvaibhavrinwa19
Acetabularia acetabulum is a single-celled green alga that in its vegetative state is morphologically differentiated into a basal rhizoid and an axially elongated stalk, which bears whorls of branching hairs. The single diploid nucleus resides in the rhizoid.
Safalta Digital marketing institute in Noida, provide complete applications that encompass a huge range of virtual advertising and marketing additives, which includes search engine optimization, virtual communication advertising, pay-per-click on marketing, content material advertising, internet analytics, and greater. These university courses are designed for students who possess a comprehensive understanding of virtual marketing strategies and attributes.Safalta Digital Marketing Institute in Noida is a first choice for young individuals or students who are looking to start their careers in the field of digital advertising. The institute gives specialized courses designed and certification.
for beginners, providing thorough training in areas such as SEO, digital communication marketing, and PPC training in Noida. After finishing the program, students receive the certifications recognised by top different universitie, setting a strong foundation for a successful career in digital marketing.
The French Revolution, which began in 1789, was a period of radical social and political upheaval in France. It marked the decline of absolute monarchies, the rise of secular and democratic republics, and the eventual rise of Napoleon Bonaparte. This revolutionary period is crucial in understanding the transition from feudalism to modernity in Europe.
For more information, visit-www.vavaclasses.com
Francesca Gottschalk - How can education support child empowerment.pptxEduSkills OECD
Francesca Gottschalk from the OECD’s Centre for Educational Research and Innovation presents at the Ask an Expert Webinar: How can education support child empowerment?
Embracing GenAI - A Strategic ImperativePeter Windle
Artificial Intelligence (AI) technologies such as Generative AI, Image Generators and Large Language Models have had a dramatic impact on teaching, learning and assessment over the past 18 months. The most immediate threat AI posed was to Academic Integrity with Higher Education Institutes (HEIs) focusing their efforts on combating the use of GenAI in assessment. Guidelines were developed for staff and students, policies put in place too. Innovative educators have forged paths in the use of Generative AI for teaching, learning and assessments leading to pockets of transformation springing up across HEIs, often with little or no top-down guidance, support or direction.
This Gasta posits a strategic approach to integrating AI into HEIs to prepare staff, students and the curriculum for an evolving world and workplace. We will highlight the advantages of working with these technologies beyond the realm of teaching, learning and assessment by considering prompt engineering skills, industry impact, curriculum changes, and the need for staff upskilling. In contrast, not engaging strategically with Generative AI poses risks, including falling behind peers, missed opportunities and failing to ensure our graduates remain employable. The rapid evolution of AI technologies necessitates a proactive and strategic approach if we are to remain relevant.
June 3, 2024 Anti-Semitism Letter Sent to MIT President Kornbluth and MIT Cor...Levi Shapiro
Letter from the Congress of the United States regarding Anti-Semitism sent June 3rd to MIT President Sally Kornbluth, MIT Corp Chair, Mark Gorenberg
Dear Dr. Kornbluth and Mr. Gorenberg,
The US House of Representatives is deeply concerned by ongoing and pervasive acts of antisemitic
harassment and intimidation at the Massachusetts Institute of Technology (MIT). Failing to act decisively to ensure a safe learning environment for all students would be a grave dereliction of your responsibilities as President of MIT and Chair of the MIT Corporation.
This Congress will not stand idly by and allow an environment hostile to Jewish students to persist. The House believes that your institution is in violation of Title VI of the Civil Rights Act, and the inability or
unwillingness to rectify this violation through action requires accountability.
Postsecondary education is a unique opportunity for students to learn and have their ideas and beliefs challenged. However, universities receiving hundreds of millions of federal funds annually have denied
students that opportunity and have been hijacked to become venues for the promotion of terrorism, antisemitic harassment and intimidation, unlawful encampments, and in some cases, assaults and riots.
The House of Representatives will not countenance the use of federal funds to indoctrinate students into hateful, antisemitic, anti-American supporters of terrorism. Investigations into campus antisemitism by the Committee on Education and the Workforce and the Committee on Ways and Means have been expanded into a Congress-wide probe across all relevant jurisdictions to address this national crisis. The undersigned Committees will conduct oversight into the use of federal funds at MIT and its learning environment under authorities granted to each Committee.
• The Committee on Education and the Workforce has been investigating your institution since December 7, 2023. The Committee has broad jurisdiction over postsecondary education, including its compliance with Title VI of the Civil Rights Act, campus safety concerns over disruptions to the learning environment, and the awarding of federal student aid under the Higher Education Act.
• The Committee on Oversight and Accountability is investigating the sources of funding and other support flowing to groups espousing pro-Hamas propaganda and engaged in antisemitic harassment and intimidation of students. The Committee on Oversight and Accountability is the principal oversight committee of the US House of Representatives and has broad authority to investigate “any matter” at “any time” under House Rule X.
• The Committee on Ways and Means has been investigating several universities since November 15, 2023, when the Committee held a hearing entitled From Ivory Towers to Dark Corners: Investigating the Nexus Between Antisemitism, Tax-Exempt Universities, and Terror Financing. The Committee followed the hearing with letters to those institutions on January 10, 202
2. 2015, tim.menzies@gmail.com,
http://creativecommons.org/licenses/by/4.0/
REQUIREMENTS
ENGINEERING
Key points
• Requirements = early life cycle guesses
• And guessing is hard, particularly about the future
• More than just UML
• UML = constructs for the programmer stakeholders
• Need other notations for other stakeholders
• Ultra-light weight notations. Write fast, reason fast
• Requirements, done right, fuels planning
• and iterative development
• Stakeholders
• There are more than one (with conflicting views)
2
11. 2015, tim.menzies@gmail.com,
http://creativecommons.org/licenses/by/4.0/
REQUIREMENTS
ENGINEERING
Stakeholders have
different “non-functional
requirements”
11
Time
• Transactions / sec
• Response time
• Time to complete an operation
Space
• Main memory
• Auxiliary memory
• (Cache)
Usability
• Training time
• Number of choices
• Mouse clicks
Reliability
• Mean time to failure
• Downtime probability
• Failure rate
• Availability
Robustness
• Time to recovery
• % of incidents leading to
catastrophic failures
• Odds data corruption after failure
Portability
• % of non-portable code
• Runs on N operating systems
• Runs on desktop, tablet, mobile
Etc
15. 2015, tim.menzies@gmail.com,
http://creativecommons.org/licenses/by/4.0/
REQUIREMENTS
ENGINEERING
The Geneis crash landing
• NASA sample return probe
• collected a sample of solar wind
• returned it to Earth for analysis
• Then crash landed in Utah in 2004
• Landing chute did not deploy
• Design error
• Acceleration installed backwards
• Cost
• $164 million for spacecraft development and science instruments
• $45 million for operations and science data analysis.
• Mistake have been made worse by reuse
• Same design in the (already launched) Stardust cometary sample return craft
• Stardust landed successfully in 2006.
15
18. 2015, tim.menzies@gmail.com,
http://creativecommons.org/licenses/by/4.0/
REQUIREMENTS
ENGINEERING
Scope of Software Project Failures
WHY PROJECTS FAIL %
1. Incomplete Requirements 13.1
2. Lack of user involvement 12.4
3. Lack of resources 10.6
4. Unrealistic Expectations 9.9
5. Lack of executive support 9.3
6. Changing requirements 8.7
7. Lack of planning 8.1
8. Didn’t need it any longer 7.5
9. Lack of IT management 6.2
10. Technology illiteracy 4.3
Jim Johnson, The Standish Group International Project Leadership
Conference, May 1995, Chicago
18
19. 2015, tim.menzies@gmail.com,
http://creativecommons.org/licenses/by/4.0/
REQUIREMENTS
ENGINEERING
Relative Cost to Fix an Error
Phase in Which Found Cost Ratio
Requirements 1
Design 3-6
Coding 10
Development testing 15-40
Acceptance testing 30-70
Operation 40-1000
Boehm’s analysis of 63 s/w development projects (IBM, GTE, TRW, etc.) to
Determine ranges in cost for errors created by false assumptions in req’ts phase
But not detected till later phases
19
27. 2015, tim.menzies@gmail.com,
http://creativecommons.org/licenses/by/4.0/
REQUIREMENTS
ENGINEERING
Some Requirements Notations
• Main thing to note:
• Miles and miles above UML diagrams
• At the requirements layer
• Details of classes, states, etc
• Are tiny peripheral details
• Q: Why?
• A: Language levels
• When you talk to programmers
• They want to talk “what” and “how”
• When you talk to high-end business users
• They want to talk about “why” and “why not”
27
30. 2015, tim.menzies@gmail.com,
http://creativecommons.org/licenses/by/4.0/
REQUIREMENTS
ENGINEERING
Example #1:
DDP @ NASA
• DDP: graphical notation of
• requirements being explored,
• risks that everyone thinks
might damage those
requirements,
• mitigations that might be put in
place to reduce those risks.
• After a few days, those
diagrams can very complex,
• particularly if you are seeking
• the least cost combination of
mitigations
• that retire the most risks
• enabling more requirements
30
32. 2015, tim.menzies@gmail.com,
http://creativecommons.org/licenses/by/4.0/
REQUIREMENTS
ENGINEERING
Example #2: Feature maps
• Design product line
[Kang’90]
• Add in known constraints
• E.g. “if we use a camera
then we need a high
resolution screen”.
• Extract products
• Find subsets of the product
lines that satisfy
constraints.
• If no constraints, linear time
• Otherwise, can defeat
state-of-the-art optimizers
[Pohl et at, ASE’09]
[Sayyad, Menzies ICSE’13].
32
Cross-Tree
Constraints
34. 2015, tim.menzies@gmail.com,
http://creativecommons.org/licenses/by/4.0/
REQUIREMENTS
ENGINEERING
Example #2: Feature maps
WHY?
• Software is changing
• product-based to app-based,
• Before
• Vendors locked in their user base via some complete solution to all their
anticipated needs (e.g. Microsoft Office).
• Large software platforms are very complex and, hence, very slow to change.
• Enter smart phones and tablet-based software,
• users can choose from large numbers of small apps from different vendors,
• each performing a specific small task.
• App-orientedsoftware engineering,
• vendors must quickly and continually reconfigure their apps in order to retain
and extend their customer base.
• demands a new style of feature-based analysis
• Feature maps are a lightweight method for defining a space of
options
• And assessing the value of a particular subset of those options.
34
36. 2015, tim.menzies@gmail.com,
http://creativecommons.org/licenses/by/4.0/
REQUIREMENTS
ENGINEERING
Example #2: Feature maps
Reasoning on feature maps: 2,3,4,5
goals
36
Software engineering = navigating the user goals:
1. Satisfy the most domain constraints (0 #violations 100%)≤ ≤
2. Offers most features
3. Build “stuff” In least time
4. That we have used most before
5. Using features with least known defects
Binary goals= 1,2
Tri-goals= 1,2,3
Quad-goals= 1,2,3,4
Five-goals= 1,2,3,4,5
37. 2015, tim.menzies@gmail.com,
http://creativecommons.org/licenses/by/4.0/
REQUIREMENTS
ENGINEERING
HV = hypervolume of dominated region
Spread = coverage of frontier
% correct = %constraints satisfied
37
Abdel Salam Sayyad, Tim Menzies, Hany Ammar:
On the value of user preferences in search-based software engineering: a case study in software product lines. ICSE 2013: 492-501
Example in bi-goal space
Note: example on next slide reports
HV, spread for bi, tri, quad, five objective space
Example #2: Feature maps
Reasoning , performance measures
38. 2015, tim.menzies@gmail.com,
http://creativecommons.org/licenses/by/4.0/
REQUIREMENTS
ENGINEERING
HV = hypervolume of dominated region
Spread = coverage of frontier
% correct = %constraints satisfied
38
Very similarVery different, particularly in % correct
Abdel Salam Sayyad, Tim Menzies, Hany Ammar:
On the value of user preferences in search-based software engineering: a case study in software product lines. ICSE 2013: 492-501
Continuous
dominance
Binary
dominance
ESHOP: 290 features, 421 rules
[Sayyad, Menzies ICSE’13]
39. 2015, tim.menzies@gmail.com,
http://creativecommons.org/licenses/by/4.0/
REQUIREMENTS
ENGINEERING
State of the Art
39
Features
9
290
544
6888
Pohl ‘11Pohl ‘11 Lopez-
Herrejon
‘11
Lopez-
Herrejon
‘11
Henard ‘12Henard ‘12
Sayyad,
Menzies’13
a
Sayyad,
Menzies’13
a
Velazco
‘13
Velazco
‘13
Sayyad,
Menzies’13b
Sayyad,
Menzies’13b
Johansen
‘11
Johansen
‘11
Benavides ‘05Benavides ‘05
White ‘07, ‘08, 09a, 09b,
Shi ‘10, Guo ‘11
White ‘07, ‘08, 09a, 09b,
Shi ‘10, Guo ‘11
Objectives
Multi-goalSingle-goal
300,000+
clauses
41. 2015, tim.menzies@gmail.com,
http://creativecommons.org/licenses/by/4.0/
REQUIREMENTS
ENGINEERING
Example #3: Another requirements
ontology: Mylopoulos et al.
Nodes
• Goals
• Goal ependencies are used to represent
delegation of responsibility for fulfilling a
goal;
• Softgoal:
• Subjective criteria, things we strive to
achieve to some degree.
• May be traded off if necessary
• Depender (D), dependee (d)
• Task dependencies are used in situations
where the dependee is required to
perform a given activity;
• Resource dependencies require the
dependee to provide a resource to the
depender
Edges
• Edges
• Dependency (D to d)
• Part-of (decomposition)
• Means-end link
41
47. 2015, tim.menzies@gmail.com,
http://creativecommons.org/licenses/by/4.0/
REQUIREMENTS
ENGINEERING
The Requirements Document
• 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
• Also, it should have tests that can be applied
incrementally
• See “commit partition”, below
47
48. 2015, tim.menzies@gmail.com,
http://creativecommons.org/licenses/by/4.0/
REQUIREMENTS
ENGINEERING
Requirements Document Structure (1)
• Introduction
• Describe need for the system and how it fits with business
objectives
• Glossary
• Define technical terms used
• System models
• Define models showing system components and
relationships
• Functional requirements definition
• Describe the services to be provided
• User stories go here
• Add in notes for the commit partition here
48
49. 2015, tim.menzies@gmail.com,
http://creativecommons.org/licenses/by/4.0/
REQUIREMENTS
ENGINEERING
Requirements Document Structure (2)
• Non-functional requirements definition
• Define constraints on the system and the development process
• Add in notes for the commit partition here
• Constraints
• Add in notes for the commit partition here
• System evolution
• Define fundamental assumptions on which the system is based
and anticipated changes
• Requirements specification
• Detailed specification of functional requirements
• Appendices
• System hardware platform description
• Database requirements (as an ER model perhaps)
• Index
49
51. 2015, tim.menzies@gmail.com,
http://creativecommons.org/licenses/by/4.0/
REQUIREMENTS
ENGINEERING
Product Constraints
restrictions & limitations that apply to the product & problem
1. Purpose of Product - the reason for building it and the
business advantage if we do so
2. Stakeholders - the people with an interest in the product
3. Users - the intended end-users, & how they affect the
product’s usability
4. Requirements Constraints - limitations on the project &
restrictions on product’s design
5. Naming Conventions & Definitions - vocabulary of the
product
6. Relevant Facts - outside influences that make some
difference to this product
7. Assumptions - that the developers are making
51
52. 2015, tim.menzies@gmail.com,
http://creativecommons.org/licenses/by/4.0/
REQUIREMENTS
ENGINEERING
Constraints Are:
• global requirements that shape the requirements
• apply to the entire product
• The users of a product are a constraint since they
dictate usability of the product:
• Constraints may also be placed on the eventual
design and construction of the product:
Passengers on board an aircraft will use the product.
The product shall run on the company’s existing UNIX
machines.
52
54. 2015, tim.menzies@gmail.com,
http://creativecommons.org/licenses/by/4.0/
REQUIREMENTS
ENGINEERING
Functional Requirements Are:
• Things the product must do
• An action that the product must take to provide
functionality for its user
• Arise from the fundamental reason for the
product’s existence
-> Something systems must do if it is to be useful within
the context of the customer’s business needs.
The product shall produce an amended de-icing schedule when a
change to a truck status means that previously scheduled work
cannot be carried out as planned.
54
55. 2015, tim.menzies@gmail.com,
http://creativecommons.org/licenses/by/4.0/
REQUIREMENTS
ENGINEERING
Non-Functional Requirements
the products qualities
10. Look & Feel Reqt’s - the intended appearance
11. Usability Reqt’s - based on the intended users
12. Performance Reqt’s - how fast, big, accurate, safe
reliable, etc.
13. Operational Req’ts - the product’s intended operating
envt.
14. Maintainability & Portability Reqt’s - how changeable
the product must be
15. Security Reqt’s - the security, confidentiality & integrity of
the product
16. Cultural & Political Reqt’s - human factors
17. Legal Reqt’s - conformance to applicable laws
55
57. 2015, tim.menzies@gmail.com,
http://creativecommons.org/licenses/by/4.0/
REQUIREMENTS
ENGINEERING
Non-Functional / Quality Requirements
Are:
• properties, or qualities, that the product must have
• may be critical to the product’s success
• some NFRs may simply enhance the product:
• NFRs are usually attached to the product’s functionality
• E.g., how it will behave, qualities it is to have, how big or fast it should be
The product shall determine ‘friend or foe’ in less than 0.25
seconds.
The product shall use company colors, standard company logos
and standard company typefaces.
57
58. 2015, tim.menzies@gmail.com,
http://creativecommons.org/licenses/by/4.0/
REQUIREMENTS
ENGINEERING
Project Issues
apply to the project that builds the product
18. Open Issues - as yet unresolved issues w/ a possible
bearing on the product’s success
19. Off-the-Shelf Solutions - components that may be used
instead of building something
20. New Problems - caused by the introduction of new
product
21. Tasks - things to be done to bring the product into
production
22. Cutover - tasks to convert from existing systems
23. Risks - the risks the project is most likely to face
24. Costs - early estimates of cost or effort needed to build it
25. User Documentation - plan for building user
documentation
26. Waiting Room - req’ts to be included in future releases
58
62. 2015, tim.menzies@gmail.com,
http://creativecommons.org/licenses/by/4.0/
REQUIREMENTS
ENGINEERING
Is there more than one design?
• Assessing options of criteria
• predictability (1), security (2), adaptability (3), coordinability (4),
cooperativity (5), availability (6), integrity (7), modularity (8), or
aggregability (9)
• Which is best? Dunno. Ask your stakeholders!
• But add value to their discussions
• Give them considered conclusions to aid their decisions
62
65. 2015, tim.menzies@gmail.com,
http://creativecommons.org/licenses/by/4.0/
REQUIREMENTS
ENGINEERING
Check for ambiguity in Stating
Requirements
• Missing requirements
• (e.g. structure, functions, physical env’t.)
• Ambiguous words
• E.g., small does not adequately specify the size of the group
• E.g., group implies that the people will interact, but it’s not clear how
• Introduced elements
• E.g., Structure - “create a means” or “design a structure”
[Gause and Weinberg 1989]
65
67. 2015, tim.menzies@gmail.com,
http://creativecommons.org/licenses/by/4.0/
REQUIREMENTS
ENGINEERING
Identify the Requirements
“Classes”
• Enduring requirements
• Stable requirements derived from the core activity of the
customer organization.
• E.g. a hospital will always have doctors, nurses, etc.
• May be derived from domain models
• Volatile requirements
• Requirements which change during development or when
the system is in use.
• In a hospital, requirements derived from health-care policy
67
72. 2015, tim.menzies@gmail.com,
http://creativecommons.org/licenses/by/4.0/
REQUIREMENTS
ENGINEERING
As to the real value of requirements….
• Ideally, we look before we leap
• Find best ways to do proceed
• And we don’t get it wrong
• In reality, our initial peeks are wrong
• Need extensive modification
• If you want God to laugh, tell her your plans
• Recent research says requirements are an illusion
• Cognitive phenomena including anchoring bias, fixation and confirmation bias
• Misrepresenting decisions as requirements in situations where no real requirements
are evident.
• Misrepresenting an incidental feature as a requirement will reduce exploration of the
design space, curtailing innovation
• Nevertheless, sometime in your career,
• you will be asked “how do we start?”
• Welcome to the black art of requirements engineering
72