New answers tagged requirements
1
Onboarding is an opportunity, when done right.
It's all about the goals, if the only goal of the onboarding is to have another productive member of the team, all the onboarding tasks will be a dreading wasteful time.
On the other hand, onboarding a new team member creates the opportunity to distribute knowledge, test current team's assumptions and ways of ...
4
TL;DR: No. Onboarding is a waste.
Time and effort invested "Onboarding" is neither a functional or a non-functional requirement. In our project, we had failed to find how to address such situations within normal agile frameworks, and even on the agile manifesto itself. We went deeper and found a potential answer for such situations in agile's ...
0
Doing some work and preparing some jira tickets for it has no relation to "non functional requirements".
A requirement is not the work to fulfill the requirement, independent if it is a functional or nonfunctional one.
In your case, the requirement is "want to be able to use tool xyz". To fulfill these requirement, you have to "add ...
3
Non-functional requirements aren't an Agile concept - they very much pre-date agility. Non-functional requirements are about any of the criteria that don't relate to specific behaviors of the system under design.
I don't think that an onboarding flow would be a non-functional requirement, but the attributes including usability, supportability, and ...
1
You should treat the developers as Subject-Matter Experts (SMEs) with regard to how the existing system works and therefore how the requested functionality can be implemented – or, indeed, if it can.
A purely-abstract "functional requirement" simply says that "the software needs to be able to 'do' this." But, as Perl programmers love to ...
1
Within a Scrum team, coming up with the requirements is usually part of the Product Owner's job - he or she represents the customer and its needs, desires, problems - and how "we as a team" shall address them and deliver a product (and within Scrum, we usually focus on the Sprint and its deliverables / the Increment) for meeting them.
Therefore I ...
1
Very clearly they should.
Until they do, we will will be stuck with the current process, which boils down to:
Project Manager: "Does what we have meet the design spec?"
Techies: "Pretty much, but we've noticed this, that and the other…"
PM: "Never you mind what you've discovered… Does what we have meet the design spec… Yes or no?&...
0
Softwaree developers know better than anyone else what can be implemented, and at what cost. And software developers are usually quite clever.
You can create functional requirements all you want, but if you don't involve the developers early they might tell you that your functional requirements cannot be reasonably produced, either not at all, or only by a ...
5
Anyone can have a say in the product requirements. Even the analyst's mistress may offer some input. That said, it is analysts' job to analyze, combine, synthesize, and prioritize both requirements and requirements sources.
Consider the following:
Customers (rarely but still) can explain what their difficulties are
Engineers can help to understand technical ...
-3
It is not the role of a developer to have a say in the defining of functionality in a project. The design of the project is based on the end user and any other stakeholders based on business requirements not on any specific technical issue. Developers sometimes just don't understand the difference between not knowing about a task and how to think about how ...
8
Developer here. I have seen projects fail because a functional requirement was impossible to implement. I'll tell you a tale where I was involved.
We were working with a piece of hardware that allowed you to capture TV signal. It came with its own software that allowed you to tune in to channels and watch TV in your computer. This was before digital TV was ...
0
I am going to take a bit of a different view than the other two answers. Role boundaries are a thing for a very good reason. People departing from their role and assuming tasks in another, while maybe good intentioned, can cause a lot of issues. In the workplace, folks jump out of their swim lane all the time and, while at times it may have been helpful, ...
20
I fail to see how you can carry out requirements engineering activities effectively without the involvement of developers.
A business analyst or product manager may be very good at working with stakeholders to understand their needs and how to close the gap between the current state of the product and the stakeholder need. However, requirements also need to ...
12
Everyone in a development team should take responsibility for and be involved in requirements gathering to some extent, otherwise you have barriers to effective teamwork.
"The best architectures, requirements, and designs emerge from self-organizing teams" (agilemanifesto.org) Development teams follow that dictum by not limiting people to specific ...
Top 50 recent answers are included
