Architecture-based problem frames constructing for software reuse
Proceedings of the 2006 international workshop on Advances and applications of problem frames
Eliciting Web application requirements - an industrial case study
Journal of Systems and Software
Incorporating usability requirements in a test/model-driven web engineering approach
Journal of Web Engineering
Expanding the horizons of software development processes: a 3-D integrated methodology
SPW'05 Proceedings of the 2005 international conference on Unifying the Software Process Spectrum
How architects see non-functional requirements: beware of modifiability
REFSQ'12 Proceedings of the 18th international conference on Requirements Engineering: foundation for software quality
Introducing usability in a conceptual modeling-based software development process
ER'12 Proceedings of the 31st international conference on Conceptual Modeling
| Hi-index | 0.00 |
The worst thing that can happen in requirements engineering is that your set of requirements, however expressed, doesn't accurately represent your users' needs and consequently leads your team down the wrong development path. The whole point of requirements engineering is to steer your development toward producing the right software. If you don't get the requirements right, how well you execute the rest of the project doesn't matter because it will fail. The article looks at how we can be led astray