Using business use cases vs user stories in a new requirement procedure?

Question

Actually in the company that I work there isn't a procedure or any kind of methodology choose to develop software. The software developed is administrative to the own company, clients applications many of them data driven and some outsourcing wherever the occasion arise. My manager give me the task to create a set of procedures for the SDLC(Software Development Life Cycle), knowing that in the near future will be implementing SCRUM.

I've read and research a lot about different approaches to the requirement phase and I find a pretty good book, Mastering the Requirements Process, that describe a methodology that I think it can benefit the company (because sometimes the software is produce without thinking in the main problem or process) which is the Volere Requirements Specification Template.

I've not finish reading the book and I have to hand over a draft of the procedure and I'm pretty confused in too things:

1. Taking in account that SCRUM is something that may take time for the team to understand and learn, should I use the user stories or business use case to specify the requirements or both. (I'm not asking about the difference because they are a lot of answers about that already).

2. In the Agile Manifesto, Scrum Methodology there is a principle that is working software over documentation, which is logic, because requirements are always changing. In the book there are some examples that establish in what kind of projects it's needed more formality, in the case of quick and not so formal projects named "Rabbit Projects" the authors always said that is not needed to have the requirement in a SRS documentation, how then can the stakeholders and software team have a clear understanding of what it's need to be done if is not documented?

Answer 1

User Stories or Business Use Case

Most people are surprised to learn that the official scrum guide does not even mention User Stories, just Backlog Items. This is for a good reason: Their form is just too project specific. In most cases, especially for beginners, User Stories are a good idea. But it is up to the Team to decide how to organize itself. That's why we cannot tell you which one to use, it depends on your team and its environment. Talk to your team, find an agreement for a couple of sprints, then use the retrospective to learn from your experience and decide how to proceed.

Clear understanding without documentation

Clear understanding without documentation is primarily achieved by frequent face-to-face communication. Besides, the Agile Manifesto is not against documentation, it just claims that working software is more important. Again, you will have to come together with your team and decide which and how much documentation is useful for you.